Open a Socket!

Have you noticed that sometimes SQL Server Management Studio takes a really long time to start up?  I’ve found it can take up to half a minute or longer, which is really annoying if you tend to use it regularly.  A few weeks back I was doing some work on a customer site with Tracey Davis from SQL Services and she gave me this handy tip to speed things up.

On the machine displaying the slowness, open up Internet Explorer.  Go to Tools -> Internet Options -> Advanced and scroll down to the Security section.  Uncheck the "Check for publisher’s certificate revocation" checkbox and apply the change.  After this your SSMS should start much more quickly.

The reason why this works is that SSMS contains signed code.  When you start up the program it tries to check that the certificates used to sign the code are valid by looking up the certificate revocation list at crl.microsoft.com.  If the computer from which you are launching SSMS does not have an Internet connection (or cannot contact crl.microsoft.com) the resulting timeout delay causes the slowness.

If you don’t want to mess with your IE settings, another option would be to add the following line to the hosts file on the affected machine.

127.0.0.1 crl.microsoft.com

This has a similar affect of improving the startup speed of SSMS.

One of the improvements to Active Directory Users and Computers (DSA.MSC) in Windows Server 2008 is the "protection from accidental deletion" feature.  This blog article explains what the feature is and how it works under the hood.

Probably the most common cause of restore operations in AD is accidental deletion of objects.  Administrators with fat fingers can fairly easily delete a single object, an OU or an entire OU tree.  Windows Server 2008 provides a handy checkbox that protects an object from accidental deletion.  The screenshot below shows the checkbox selected by default during the creation of a new OU.

The checkbox is subsequently available on the Object tab of the object’s properties, as shown below.  Note that the protection is not just for OUs, it can be set on the Object tab for all object types, including users.

When you attempt to delete an object in Active Directory Users and Computers, you will see the following standard warning.

If you then select Yes, and the object is protected from accidental deletion you will see the error message, "You do not have sufficient privileges to delete <object_name>, or this object is protected from accidental deletion", as shown below.

To go ahead and delete the object you have to go back to the object’s properties, deselect the checkbox on the Object tab and then try the deletion again.

So how is this feature implemented behind the scenes?  Well, it’s simply really.  When the checkbox is selected, two new "Deny" access control entries (ACEs) are added to the discretionary access control list (DACL) in the object’s security descriptor.  These explicitly deny everyone permission to delete the object and/or delete the subtree.   The screenshot below shows the entries in the Security -> Advanced view of the object’s properties.   An explicit Deny entry beats an Allow entry, which effectively means the object cannot be deleted by anyone without first removing the ACEs, either by editing the security directly or toggling the accidental deletion checkbox on the Object tab.

It may not represent a radical change to AD like the RODC or Fine-Grained Password Policies, but Microsoft has done a good job in providing a simple-yet-effective method of protecting objects from accidental deletion in Windows Server 2008. 

Those of you already familiar with Windows Server 2008 will know that one of the key Active Directory-related improvements is the introduction of the Read-Only Domain Controller (RODC).  With the RODC comes the ability to separate administrative roles.  This removes the restriction of having to use a Domain Administrators account when carrying out administrative tasks on a DC.   For example, changing the Network Card on a Domain Controller on a Windows Server 2003 DC requires a Domain Admin account, which is clearly overkill.  On a Windows Server 2008 RODC you can now delegate machine-specific administrative tasks to a local administrator.  The delegated account requires no elevated privileges within AD. 

You can specify an account or group to be the the local administrator for a RODC when pre-staging the creation of the RODC on a writeable DC (or at a later time if you prefer).  This pre-staging activity (also new in Windows Sever 2008) delivers the ability to complete the promotion of the RODC using the account (or members of the group) you specified to be the local administrator.  In the example below, I have specified a group named RODC1 Local Admins to be the local administrator for the RODC1 Domain Controller.  Note that the group name I use specifies the the machine name (i.e. RODC1).  This is because the group will typically be used for only one RODC, rather than for all RODCs.

The group or account that you specify will be assigned to the managedBy attribute value of the RODC’s computer object in AD.

You can then use the account (or member of the group you created if you used a group) to complete the promotion of the RODC by running DCPROMO on the server that is to become the RODC (see below).   Again, bear in mind that the account used does not need to be a member of Domain Admins.  You will however receive a warning during the DCPROMO process (see below), which you can safely ignore when completing the promotion of a pre-staged RODC.

The local administrator account can then subsequently be used to log on locally to the RODC and to perform administrative tasks.  Remember that the account will only have local administrator rights to the local RODC. 

We know that the managedBy attribute for the RODC is used to store the account or group that is allowed local administrator rights on the RODC.  But the authentication mechanism needs to provide for scenarios where AD is not available, so how is this information actually used by the RODC?   The information is actually stored in the registry on the RODC in the following location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RODCROLES

As you can see from the screenshot below, the Security Identifier (SID) shown in the “Repair Admins” REG_SZ value corresponds to the account or group specified in the managedBy attribute value on the RODC’s AD object.

Hint: You can use the SID Lookup feature of LDP.EXE to match a  SID to a friendly name.

If you need to include additional local roles, you can use the “Local Roles” feature within NTDSUTIL.   You can define the following local roles

Administrators
Users
Guests
Remote Desktop Users
Network Configuration Operators
Performance Monitor Users
Performance Log Users
Distributed COM Users
IIS_IUSRS
Cryptographic Operators
Event Log Readers
Certificate Service DCOM Access
Incoming Forest Trust Builders
Terminal Server License Servers
Pre-Windows 2000 Compatible Access
Windows Authorization Access Group
Print Operators
Server Operators
Account Operators
Backup Operators
Replicator

When a new local role has been defined, it will appear within the same RODCROLES registry key with a relative identifier that corresponds to the role.  In the example below, an account named “morgaaa” has been assigned the Print Operators local role. 

C:\Windows\system32\ntdsutil.exe: lo ro
local roles: add morgaaa “print operators”
Successfully updated local role.
local roles: show role “print operators”
        TMAD\morgaaa
local roles:

Given that the registry values show the relative identifer (e.g. 550), rather than the the friendly name (e.g. Print Operators) you can use the Microsoft KB article Well-known security identifiers in Windows operating systems to match the registry value to the role.

Remember to ensure that the passwords for the domain accounts used for local roles are cached on the RODC.   Unless you do this, you will not be able to log on to the RODC in situations where other DCs are not available (e.g. when the network link from the Branch office to the hub site is down).

The way in which the local roles are assigned and used is currently not well documented.  Hopefully this blog entry provides you with some useful additional information on how this new Windows Server 2008 feature.

Today I installed Outlook 2007 on a test machine and enabled the RSS defaults.  An hour or so later I noticed that the Junk Mail folder contained 60 items.  Curious as to what might be in there so quickly, I found it was RSS items from MSNBC.com. 

Interesting that one Microsoft product considers another to be Junk. 

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.

If you’ve managed to get some hands-on experience with the RTM Windows Server 2008, you might be surprised to see the version shown as Service Pack 1.  Relax, you haven’t been in a coma - this really is what the RTM release calls itself (see below).

The reason for Service Pack 1 moniker is so that service packs and patches for Vista and Windows Server 2008 can be streamed together.  From a customer perspective this is potentially less confusing than was the case with, say, Windows XP and Windows Server 2003 where the service packs were not aligned. 

The cynical among us might also consider than many organisations hold off from deploying a new Microsoft release until at least SP1.  In other words, this is perhaps a clever ploy from Microsoft to push customers towards early adoption.

One interesting facet of the close alignment between the Vista and Windows Server 2008 is that it appears to have caused some confusion with BgInfo, as shown in the screenshot below from a Windows Server 2008 machine.

If you’ve never watched Fox’s TV series ‘24′, the name of this blog will mean little to you.  On the other hand if you have watched the series you will recognise that the term “open a socket” is CTU’s panacea for all ills.  Will Jack escape the building surrounded by bad guys?  Sure, all he has to do is get Chloe/Michelle/Tony to “open a socket” and download the building’s blueprints to his PDA.  It happens in a matter of seconds.

Now why doesn’t my PDA do that?