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.
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).
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.
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.
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).
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.
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.
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.
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:
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.
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:
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.”
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.
Just 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).
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.