Zoho Banner September 2011

Archive for April, 2008


I sometimes have to work in environments where I have to use the customer’s PC instead of my laptop.  This can be quite frustrating as my laptop is quite heavily customised and has all the tools that I need.  One thing I find problematic is having to work with scripts (especially VBScript) without a decent script editor.  Notepad doesn’t really cut the mustard. :-)

If the PC I am assigned to has Office installed I usually fire up the Microsoft Script Editor (MSE7.EXE) when working with scripts.  This underutilised editor has a sufficiently rich set of features to make working with VBScript a comfortable experience.

The Microsoft Script Editor is normally installed by default with Office 2007, but is not reachable directly from the Start -> All Programs -> Microsoft Office menu.  Instead, you can usually find it by searching for MSE7.EXE on the local drives.  On the machine I am working on now, it is installed in the following location:

%programfiles%\Common Files\Microsoft Shared\OFFICE12\MSE7.EXE



Okay, okay, so I’m a little behind the times.  “Welcome to the nineties, dude!”, as a friend of mine would say.  I can’t help it – I’m the one who thinks this whole Interweb thing is just a fad. :-)

Anyway, I’m working with a new laptop (Dell Latitude D830) that, apart from being the size of a dining room table, has some reasonably good specs.  The key thing about the D830 is that it has a 64-bit chipset.  This means that, although the operating system is the 32-bit version of Windows XP, I have the ability to run 64-bit VMWare Virtual Machine guests.  Getting the system to the point where I could fire up a 64-bit guest took a while, so I thought I would share my experiences here.

The first step is to determine whether your host machine hardware is capable of running 64-bit guests.  There are two methods I came across for doing this.

Method 1.  VMWare Processor Check for 64-Bit Compatibility

Download the tool from http://www.vmware.com/download/server/drivers_tools.html

The tool itself is tiny and gives a minimalist output when successful, as shown in the screenshot below.


Method 2.  CPU-Z

CPU-Z is a handy little freeware utility from http://www.cpuid.com/cpuz.php and provides information on some of the main devices of your system.  More importantly, it provides detailed information relating to your processor.


In my case it tells me that my processor is an Intel Mobile Core Duo T7500 (codename “Merom”).  The EM64T (Extended Memory 64 Technology) tag is important in that it indicates that the CPU is based on Intel’s 64-bit technology.  EM64T was the original name and has now been superseded by the term “Intel 64″.

Armed with the processor information from Method 2, I then used Google to try to confirm whether the model supports Virtualization Technology (VT).  Some CPU models that are based on EM64T architecture (like the one in my home PC!) are not VT-capable, which means that they do not support virtual machines as guests.  The best information I found was, curiously enough, on Wikipedia.   The page covering the “List of Intel Core 2 Microprocessors”  quickly gave me the information I was looking for.  Regarding my “merom” CPU it had this to say:

Virtualization Technology: supported by all models except T5200, T5450 and some T5500″

Given that my model is T7500 it all looked very promising!

The next step was to check that the VT was enabled in my laptop’s BIOS.  For some bizarre reason known only to hardware manufacturers VT is typically disabled by default.  The BIOS settings obviously vary according to the manufacturer and model. For my Dell Latitude D830 the VT setting is located in the “POST Behavior” section under “Virtualization”.  POST stands for Power-on Self-Test – essentially the computer’s pre-boot sequence. As suspected, virtualization support was disabled in line with the factory default settings.

With VT was enabled in the BIOS it was all plain sailing and I am watching my Windows Server 2008 x64 guest machine run through the setup routine as I type.  The next step will be to install the 64-bit version of Exchange Server 2007 – something I have been unable to do in the lab until now.  :-)

Windows Server 2008 introduces a new security principal called OWNER RIGHTS.  It was introduced to fill a security and delegation loophole in previous versions of Windows whereby creators of objects potentially inherit more permissions than are intended.  For detailed information on how the new feature works in the context of AD, see Jorge’s blog entry here.

Having learned about OWNER RIGHTS, I had a thought that there was perhaps some potential for organisations to snooker themselves through over-enthusiastic (or downright stupid) delegation.  Taking an extreme example, was it possible to completely block administrator access to domain objects through willful abuse of OWNER RIGHTS?  Here’s how I approached the task.

First, I checked the current owner of the top of the domain tree (domainDNS object).  In my lab the domain is named DC=ad,DC=fisheagle,DC=net and the owner is set to the default Administrators group.  The only account in the Administrators group is the default Administrator account.


I then set explicit Deny entries for everything for the OWNER RIGHTS security principle and applied it to “This object and all descendant objects”.  An explicit Deny beats an Allow entry, so my thinking was that the effect would be to block the Administrator account from having any permissions on any objects in the domain.


After setting the security in this way, I tried to launch Active Directory Users and Computers (DSA.MSC) while logged in with the Administrator account and was encouraged to see the following error. :-)


When the snap-in opened, it looked very much like my Administrator account was indeed denied access to anything in the domain.  If this were a live environment with no other admin accounts, I thought, there would be some sweaty palms right about now!


That’s when I tried a few things and found a workaround.  I ran the following DSACLS command while logged in with the Administrator account:

          dsacls “DC=ad,DC=fisheagle,DC=net” /takeOwnership

It applied successfully and the effect of this was that I could then immediately get back in to manage objects in the domain.  I hadn’t expected this to work, because one of the Deny entries I had set was for “Modify permissions”.  When I had a look at the security descriptor afterwards, I saw that the OWNER RIGHTS permissions had been changed.  The explicit Deny entries were still there, but it now applied to “Nothing” instead of “This object and all descendant objects”.


I don’t usually try to break things, but sometimes it helps when learning new product features.  In this case, it was reassuring to discover that there are ways to recover from badly implemented delegation using OWNER RIGHTS.