Windows support lifecycle reminders

Last week, I wrote about the forthcoming service pack for Windows 7 and Windows Server 2008 R2.  At the other end of its support lifecycle, is Windows 2000, which finally reaches end of life (i.e. the end of extended support) on 13 July 2010.

Windows XP remains on extended support for a while longer (until 8 April 2014) but service pack 2 (SP2) also goes out of support on 13 July 2010 and, from that date onwards, Microsoft will no longer support or provide free security updates for Windows XP systems running SP2 or earlier.  Service pack 3 is available free of charge; however Windows XP users should really be planning on migration to a later version of Windows.  For details of how to obtain the latest service pack for Windows XP, see Microsoft knowledge base article 322389.

Also, on 13 July, Windows Server 2003 moves out of mainstream support and into its extended support phase.   Service pack 1 for Windows Server 2003 was retired on 14 April 2009, so service pack 2 is required in order to remain supported.  For details of how to obtain the latest service pack for Windows Server 2003 (and Windows Server 2003 R2), see Microsoft knowledge base article 889100.  Windows Server 2003 and Windows Server 2003 R2 are subject to the same support lifecycle milestones as each other.

Windows Vista with no Service Packs installed will also lose support on 13 April 2010.  Customers are advised to install service pack 2 for Windows Vista in order to remain secure and supported (although service pack 1 is still supported until 12 July 2011).  For details of how to obtain the latest service pack for Windows Vista, see Microsoft knowledge base article 935791.

Customers running Windows Server 2008 have plenty of time left in their operating system investment, although Windows Server 2008 service pack 1 will be retired on 12 July 2011.  For details of how to obtain the latest service pack for Windows Server 2008, see Microsoft knowledge base article 968849.  The same service pack is applicable to both Windows Vista and Windows Server 2008.

Announcing the Windows Server User Group (WSUG)

Back in 2008, I set up a LinkedIn group after the UK Windows Server User Group’s leader, Scotty McLeod, was involved in a tragic accident and it was originally intended to provide a temporary workaround until we got the Windows Server Team site up and running again.

Towards the end of last year Mark Parris and I had a conversation around combining the UK Active Directory User Group with the UK Windows Server User Group. The reasoning behind this was that Windows Server User Group meetings had become few and far between, meanwhile the Active Directory User Group is an active community. At the same time Active Directory touches almost every component of Windows Server (it does, after all, account for five of the Windows Server roles) and the division between Windows Server content and Active Directory content was becoming very blurred.

Consequently, the two user groups will now merge to become collectively known as the Windows Server User Group (WSUG).

Mark has set up a new website and forums and, whilst they still require some work, they share credentials and support both traditional user/password authentication and OpenID.

Meanwhile the LinkedIn group will still exist, but I’m honestly not sure that it provides any value and I would encourage members to sign up at the WSUG website, where we are trying to build an active Windows Server community with discussion forums and in-person meetings (generally held at Microsoft offices in the UK).

Twitter users can also follow @windowsserverug for event announcements, etc.

Please let us know what you would like to see on the forums and, if you would like to get more involved, please get in touch with either Mark Parris or myself.  You can find our contact details on the WSUG site.

The sun sets on Windows XP, Office 2003 and Windows Server 2003 SP1 – Vista SP1 and XP SP3 will soon be unblocked – Office 2007 SP2 to ship at the end of April – Office “14” is given a name (and will be available in both 32- and 64-bit versions)

Just in case you hadn’t noticed, today is the day that Windows XP and Office 2003 end their mainstream support phase and move onto extended support – it’s security hotfixes only from now on, unless you are prepared to pay. Security updates for Windows XP will continue to be issued via Windows Update until 8 April 2014 (ditto for Office 2003).

Whilst XP has enjoyed a longer period of mainstream support than would otherwise have been the case (due to the time it took for Microsoft to ship its successor – Windows Vista), many organisations have held back on upgrades due to the negative press that Vista has received (which may have been partially warranted at release but is not exactly valid in 2009). Regardless of the perception of Windows Vista, Windows Vista R2 [ahem] Windows 7 is receiving plenty of praise and a release candidate is widely expected to be released within the next few weeks. Those considering an eventual move to Windows 7 could prepare themselves by application testing on the beta – or even using Windows Vista as a limited pilot in preparation (the two operating systems are remarkably similar, for all but those applications that need to work at a very deep level – e.g. anti virus and VPN software).

Meanwhile, reaction to Office 2007’s “ribbon” user interface has been mixed; regardless of the many improvements in Office applications with the 2007 release, many users are still using the same basic word processing features they had in earlier versions (dare I say as far back as Word for Windows 2.0) and so organisations are needing further persuasion to upgrade – for some the business case is only justified through integration with Office server products (such as Office SharePoint Server 2007 and Office Communications Server 2007 R2) although, my personal experience of reverting to Office 2003 for a few weeks whilst my laptop was being repaired was not a happy one… it’s amazing how those “little tweaks” become embedded in your way of working after a while.

As for Windows Server, those organisations still running Windows Server 2003 (including R2) with service pack 1 lose their support today – Windows Server 2003 with service pack 2 will continue to receive mainstream support until 13 July 2010 with extended support ending on 14 July 2015.

On the subject of service packs, now is probably a good time to remind people that the service pack blocking tools for Windows Vista SP1 and Windows XP SP3 will expire on 28 April 2009 and 19 May 2009 respectively, after which time the updates will be automatically delivered via Windows Update. As for Office updates, Office 2007 service pack 2 is due for release on 28 April 2009 (including support for ODF, PDF and XPS document formats).

Looking ahead to the next release of Microsoft Office, various websites are reporting that Office codenamed “14” has been named as… no surprise here… Office 2010. APC’s David Flynn is citing delays that prevent a tandem launch with Windows 7 but I have no recollection of any announcements by Microsoft for either a joint launch or a 2009 release – and they have not even committed publicly to releasing Windows 7 this year (it’s all pure speculation by journalists, bloggers and other pundits)… how can something slip if it’s not even been formally announced? Meanwhile ARStechnica is concentrating on the availability of both 32-bit and 64-bit versions of Office 2010.

The halycon days of wholesale PC refreshes every few years may now be just a distant memory but these changes signal the need for IT departments to seriously consider their options. With Office 2010 expected to include web applications based on a monthly subscription charge, increasingly feasible online services, and desktop virtualisation becoming increasingly viable (in various forms – be that full VDI, a managed virtual desktop running on a traditional PC, or a hybrid solution using something like MED-V), these are interesting times for those given the task of providing a corporate desktop.

Managing stored credentials from the Windows command prompt using cmdkey

I’ve been meaning to blog about a command which is a reasonably recent addition to Windows for a few weeks now – cmdkey.exe (thanks to John Craddock for highlighting this at a recent XTSeminars event).

Basically Microsoft’s cmdkey, introduced with Windows Server 2003 (and which should not be confused with Jason Hood’s companion for cmd.exe), is used to create, list and delete stored security credentials.

For example, I back up the notebook PC that I use for work to my Netgear ReadyNAS using SyncToy. My ReadyNAS does not support Active Directory but it does provide SMB/CIFS access. This means that I can authenticate directly against a share but the username and password do not match the cached domain credentials on the notebook PC.

Supplying credentials each time I need to connect (or forgetting to before attempting a sync) is inconvenient, so I used cmdkey to store the username and password that I use to connect to the share:

cmdkey /add:computername /user:username /pass:password

In this case cmdkey responded as follows:

CMDKEY: Credential added successfully.


cmdkey /list


Currently stored credentials:

Target: computername
Type: Domain Password

and I can connect to a share without supplying any credentials:

net use h: \\computername\sharename

The command completed successfully.

Furthermore this drive mapping (and stored credentials) persists on reboot – when the computer is restarted, H: is visible as a disconnected drive in Windows Explorer but as soon as I double-click it I connect without a prompt to supply credentials.

Securely wiping hard disks using Windows

My blog posts might be a bit sporadic over the next couple of weeks – I’m trying to squeeze the proverbial quart into a pint pot (in terms of my available time) and am cramming like crazy to get ready for my MCSE to MCITP upgrade exams.

I’m combining this Windows Server 2008 exam cramming with a review of John Savill’s Complete Guide to Windows Server 2008 and I hope to publish my review of that book soon afterwards.

One of the tips I picked up from the book this morning as I tried to learn as much as I could about Bitlocker drive encryption in an hour, was John’s tip for securely wiping hard drives using a couple of Windows commands:

format driveletter: /fs:ntfs /x

will force a dismount if required and reformat the drive, using NTFS.

cipher /w:driveletter:

will remove all data from the unused disk space on the chosen drive.

I don’t know how this compares with third party products that might be used for this function but I certainly thought it was a useful thing to know. This is not new to Windows Server 2008 either – it’s certainly available as far back as Windows XP and possibly further.

For more tips like this, check out the NTFAQ or John’s site at

Disabling rogue server detection to avoid DHCP server activation in Windows

I’m finally in the process of switching off the Compaq Evo D510SFF PC which acted as my main server for many years until it was replaced earlier this year with some more suitable hardware (a Dell PowerEdge 840). Even though the Dell Server has been running for the last ten months, I’ve not found the time to move over a few critical services and, as I write this, the files are being transferred to my new Netgear ReadyNAS and the last two VMs are being converted for use with Hyper-V.

There were a couple of infrastructure services to transfer too – DNS and DHCP. One of the DHCP services that I wanted to run in my new infrastructure is to provide IP addresses to computers that are deliberately on a different network to my Active Directory (devices like my iPhone, the Cisco IP Phone on my desk, and guest computers using my Wi-Fi connection) but the DHCP server in Windows Server 2003 R2 wouldn’t serve clients until it had been authorised by Active Directory. I didn’t want the DHCP server to even see AD (there is a firewall between them) but so I had to find a way to make Windows think that the server is authorised.

It turns out that this occurs if the DHCP Server service is running on a workgroup server and it sees a domain-joined DHCP server on the network (for a few days during the transition, my clients could see the legacy, domain-joined, DHCP server and the new, workgroup-only, one on the same network). The answer is to create a new registry value to disable rogue detection:

Windows Registry Editor Version 5.00


After restarting the DHCP Server service, my DHCP server sprang into life and started servicing clients.

Using psexec to make registry changes on a remote computer

So, here’s the problem. I’m in the UK and I want to send a 15MB file to someone in Australia. My Windows Live SkyDrive and Mesh accounts have 5MB limits (and there is no Mac client for Mesh for a point to point connection). I have an FTP server I can use but I need to create a new user account and I’m many miles away from the server. Of course, being Internet-facing, the FTP server is in a DMZ, so I’m careful about which services it is running but I can use a Remote Desktop Connection to connect to another computer and then use a second remote desktop session to access the FTP server from inside the firewall. At least, I should have been able to, if I’d enabled remote desktop… and I hadn’t.

I tried to connect to the registry remotely and enable Remote Desktop using the method that Daniel Petri describes but that failed:

Error connecting network registry
Unable to connect to
ipaddress. Make sure you have permission to administer this computer.

I wasn’t sure what was preventing access to the remote registry (the target is a fully patched Windows Server 2003 R2 computer) but I needed another method of access. That method was a Microsoft SysInternals tool called psexec which allowed me to bypass whatever security I was having trouble with and run commands on the remote server. First I edited the registry to allow Remote Desktop:

psexec \\ipaddress -u username -p password reg add "hklm\system\currentcontrolset\control\terminal server" /f /v fDenyTSConnections /t REG_DWORD /d 0

and was pleased to see that:

reg exited on ipaddress with error code 0.

Next I checked the value I’d just set:

psexec \\ipaddress -u username -p password reg query "hklm\system\currentcontrolset\control\terminal server"

Before I restarted the server:

psexec \\ipaddress -u username -p password shutdown -f -r -t 0

After this, I could RDP onto the console and make the changes that I needed.

If all the command line exercise is a little daunting, then it looks as though Phil Morgan’s RD Enable XP will also optionally call psexec to do the same thing…

Active Directory UK user group

The number of user groups around Microsoft products seems to be increasing steadily and another group has recently started – the Active Directory UK user group (ADUG) – who aim to:

“[…] build a community of Active Directory users, be they experts or beginners, where they will be able to ask questions, share experiences and learn from each other and leading experts in the field. Regular meetings will be held, to discuss and learn about topical issues such as upgrade paths, virtualisation and compliance; these will be in addition to traditional topics such as replication, disaster recovery and administration.”

As for the Windows Server UK user group, we’re steadily building a membership in our LinkedIn group and I’ve just approached Microsoft to see about getting a room for a meeting in the autumn.

Active Directory and relative identifiers

Last night, I wrote a post about how a little logical thinking was required in order to resolve some issues with the dcdiag.exe utility from the Windows Server 2003 Support Tools.

Since then, I’ve been examining the dcdiag test results and was a little alarmed to find that two of the domain controllers (DCs) for the domain that I intend to migrate several hundred users into were reporting a lack of available RIDs:

Starting test: RidManager
   * Available RID Pool for the Domain is 17352 to 1073741823
domaincontrollername.domainname.tld is the RID Master
   * DsBind with RID Master was successful
   * rIDAllocationPool is 14352 to 14851
   * rIDPreviousAllocationPool is 12352 to 12851
   * rIDNextRID: 12849
   * Warning :There is less than 1% available RIDs in the current pool
domaincontrollername passed test RidManager

For anyone who doesn’t appreciate the potential significance of this, relative identifiers (RIDs) are necessary in order to create new Active Directory objects.  Because Active Directory uses a multi-master model, any DC can create an object, which is then replicated between the various DCs in the organisation.  Objects are actually identified by their SID, part of which includes the domain identifier, and part of which is the RID.  In order to maintain uniqueness, the generation and allocation of RIDs is controlled by the DC holding the RID Master role for the domain, allocating pools of 500 (by default) RIDs to DCs for use when generating the SIDs for new objects.  Still with me?  Microsoft knowledge base article 305475 has more details.

Active Directory DCs (at Windows 2000 SP4 and later revisions) request a new RID pool from the RID master once the pool is 50% depleted, so 1% of available RIDs concerned me somewhat.  Other tests had confirmed that replication was working, and switching the RID Master role to another DC didn’t appear to make any change.  I also checked to see that there were no duplicate SIDs in the domain.  As it happens, everything was working normally but the labels, and the warning, are very confusing. This is what I found:

  • rIDPreviousAllocationPool is not, as the name suggests, the last pool that was used – it’s actually the RID pool that is currently being used.   So, in the example above, 12352 to 12851 is the list of RIDs currently being allocated. When this becomes exhausted (rIDNextRID gives an indication of how soon this will occur), Windows copies rIDAllocationPool into rIDPreviousAllocationPool and starts using the new RIDs as needed. There is a global RID pool size limit that the RID Master can allocate from (the Available RID Pool).
  • rIDAllocationPool is the next batch of RIDs to be used (supplied by the RID Master).  In this case, 14352 to 14851 will be the next batch of RID numbers (500 in the pool) for this DC.  This is generated automatically via a request to the RID Master once the pool is 50% depleted.
  • rIDNextRID is the last RID allocated (not the next one to be allocated).  So the next object to get created in the example above will get RID 12850.

I tested this by creating some new users and running further tests with dcdiag.exe, observing the DC reach the end of the pool and then start using the next pool (originally called rIDAllocationPool):

Starting test: RidManager
   * Available RID Pool for the Domain is 17352 to 1073741823
domaincontrollername.domainname.tld is the RID Master
   * DsBind with RID Master was successful
   * rIDAllocationPool is 14352 to 14851
   * rIDPreviousAllocationPool is 12352 to 12851
   * rIDNextRID: 12851
   * Warning :There is less than 0% available RIDs in the current pool
domaincontrollername passed test RidManager

Starting test: RidManager
   * Available RID Pool for the Domain is 17352 to 1073741823 
domaincontrollername.domainname.tld is the RID Master 
   * DsBind with RID Master was successful
   * rIDAllocationPool is 14352 to 14851
   * rIDPreviousAllocationPool is 14352 to 14851
   * rIDNextRID: 14352
domaincontrollername passed test RidManager

Once I have created another 249 or so users, I should see a new rIDAllocationPool generated.

Screenshot showing the RID as part of a SID in the additional account informationJust to be sure that I understood this fully, I installed acctinfo.dll, after which I could clearly see the RID at the end of the SID for the test user account (when viewing the Additional Account Info tab on the user properties in Active Directory Users and Computers).

In short, if you see a message about less than a certain percentage of RIDs in the current pool, don’t worry about it (as long as rIDAllocationPool is different to rIDPreviousAllocationPool)!  The pool will gradually be used until it reaches 0% and tips over into the next allocation.  The problem is the confusing language used (rIDAllocationPool should really be rIDNextAllocationPool, rIDPreviousAllocationPool should really be rIDCurrentAllocationPool and rIDNextRID should be rIDPreviousRID).

Problems connecting to a Windows Server cluster

A few weeks back, I was at a Microsoft event where the presenter was struggling to connect to a Windows Server cluster using the Cluster Administrator tool. It turned out that the problem was down to having started devices in the wrong order (it should be storage, then network, then cluster nodes) but when one member of the audience suggested entering . as the cluster name in the Cluster Administrator dropdown he was able to connect to the cluster (with much relief!)… may be worth remembering for the future.