Fast forward to today. I was messing around on that system and discovered that I left that one particular GPO in place. I fired up the Group Policy Management tool and removed the link to that GPO, did a gpupdate /force on that system, rebooted and went about my business. A few minutes later, I discovered that GPO was still in effect. I double-checked that the GPO wasn’t linked to that OU anymore, and that inheritance was still blocked, and did another gpupdate /force, but to no avail. A quick check of HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\History showed that yes, the GPO was still being applied.

I did a little head scratching, and then found the answer. As it turns out, after linking the GPO to the other production OUs, I selected the ‘Enforce’ option. By doing that, even after unlinking a GPO from an OU it will continue to be applied. I simply disabled the ‘Enforce’ option, ran yet another gpupdate /force, and all was well.

TL;DR Version: If you unlink a GPO from an OU, update the system, and the GPO is still being applied, disable the ‘Enforce’ option on that policy and do another gpupdate.

I ran in to this when trying to run the tool from my Server 2003 x64-based Exchange 2007 server. It happened again when I tried to run it from a Server 2008 x64 box, and from my Windows 7 x64 workstation.

As it turns out, PFDAVAdmin requires .Net Framework 1.1 to be installed. It isn’t recommended to install that directly on to your Exchange Server as it can cause issues with .Net 2.0, so I simply installed it on my Win7 x64 box, ignored the Compatibility Warning, and that was it – PFDAVAdmin worked perfectly.

Fast forward to three years ago, just before I was hired. The then-sysadmin was getting flak for the VPN being slow, so he installed a pair of wireless routers on the roofs of the buildings and linked the two networks. However, instead of getting rid of DomainB, he simply left it in place.

Fast forward to now. Due to cost issues, the contact in the remote office was physically moved to our main building. As such, their network equipment and servers came with them, which created cramped quarters in an already cramped space. As such, I set about doing what should have been done years ago – migrating users from DomainB to DomainA.

There was a group of client computers that needed to go through a round of updates anyways, so those were simply re-imaged and joined to a separate, restricted network (DomainC) used for our clients only (this had been another pet peeve of mine – due to costs, the clients in that office were put on the same network and although they had their permissions restricted, it was still a concern in my mind). The main problem, though, was the staff workstations. Not only were they setup on DomainB, put PrimaryDC.DomainB was also an Exchange 2003 server, and TertiaryDC.DomainA was our primary mail server running Exchange 2007. The first step was to manually export the mail for the twelve staff members and create their DomainA accounts, and then get them setup on the DomainA Exchange server. Once that was up and running, the Exchange 2003 install was shutdown. Although it took a while to manually transfer the mail by exporting to .PST files and then importing it again, it was the cleanest way to do the move (and also encouraged users to clean out their mailboxes).

The last step was to actually get the users logging in to DomainA rather than DomainB. That’s where ADMT (Active Directory Migration Tool) comes in.

ADMT comes in a few ‘current’ versions. 3.0 if the server it’s running on is Server 2003, 3.1 if it’s Server 2008, and 3.2 if it’s Server 2008 R2. The source domain (B) was running on Server 2003 boxes, but the target domain (A) was running mostly on Server 2008 boxes, so I installed ADMT 3.1 on one of those.

After getting it installed and playing around with it on a test VM, I learned a few things that helped me get all of the staff workstations migrated with minimal issues:

• Setup a Two-Way Trust between the domains first, but be aware that if users are already authenticating on both domains by using store credentials, that may break unless you also setup permissions for users of both domains on effected shares.
• Double-check your DNS configuration. If both domains have separate Forward Lookup Zones (which they probably do), make sure that the DNS servers in both domains are setup to perform Zone Transfers between each other, and then check to make sure that all A and PTR records are actually correct and current.
• Make sure that the user you are logged in to on the server running ADMT is in the Domain Admins group on the target domain, and the Administrators group in primary DC on the source domain.
• Change the DNS servers that the computers to be migrated are using to the servers on the target domain. This is important, or after the computer migrations are complete you may run in to issues when logging in (for me, Active Directory decided to continually lock out user accounts of migrated users because of a missing A record in the source domain’s DNS zone).
• If you have any local firewall software running on the workstations that are to be migrated, either temporarily disable it or add exceptions for the Netlogon Service, File and Printer Sharing, and Windows Management Instrumentation (although the last may not strictly be needed – it was hit-or-miss for me).
• Run the following command on the workstations that you’re migrating: net localgroup “Administrators” “DomainAdomain admins” /ADD (changing DomainA to your target domain). This is important, as local admin rights are needed for the computer migration steps.
• If users from your source domain are using resources on your target domain and using stored credentials to authenticate, delete those stored usernames/passwords from the workstation (in most cases, open Control Panel, then User Accounts, and click ‘Manage Network Passwords’ on left). Then, once you have migrated the user accounts, give those accounts permission to access the required resources.
• During the migration, if you are trying to migrate a computer account and you continually receive an error like ERR2:7666 Unable to access server service on the machine ‘computer.domain’.  Make sure netlogon and workstation services are running and you can authenticate yourself to the machine.  hr=0×80070005. Access is denied., and you’ve run the command above on the machine to give Domain Admins from the target domain local admin rights, you may need to remove the computer from the source domain, rejoin it to the source domain to re-establish the trust relationship, and then try the migration again.
• After the migrations are done, make sure to go back to the DNS servers on your target domain and verify that the migrated computers’ PTR records reflect the new domain suffix (eg, changed from ‘workstation1.domainB.’ to ‘workstation1.domainA.’ (and leave the trailing . in, or you’ll have trouble!).

And that’s it! ADMT worked like a charm, and after using it to migrate and merge user accounts, and then migrate the computer accounts, everyone was off DomainB with out the hassle of needing to manually join DomainA and reconfigure the user accounts. By performing both the user account and computer account migrations, once the process was done users just had to login to their computers using ‘DomainAUsername’ instead of ‘DomainBUsername’ and everything was left exactly like it had been, right down to the desktop wallpaper.

And now I’m free to decommission two old servers.

I gave the user full rights to the share, and assigned it Owner status as well (all through the Security tab, as standard), and then configured the GPO as appropriate. After rebooting the client computer, however, I checked the Documents folder only to find that it was still pointing at the default location. A quick peek in to Event Viewer revealed the following error:

Failed to apply policy and redirect folder “Documents” to “\serversharefolder”.

Redirection options=0×80009211.

The following error occurred: “Can not create folder “\serversharefolder”".

Error details: “Access is denied.”.

Which was very strange indeed, as a brief check confirmed that yes, the domain user did in fact have full access to both the folder and the share.

Then, something I saw (and stupidly, ignored) when setting up the GPO came back to me. I fired up the GPO editor and and browsed back to the Documents folder redirection section (User ConfigurationPoliciesWindows SettingsFolder Redirection). After double-clicking the Documents option, and then switching to the Settings tab (shown below), I noticed the top two boxes (“Grant User Exclusive Rights to Documents” and “Move the Contents of Documents to the New Location”) were selected by default. Given that this was an ‘Access Denied’ error, I figured one of these two settings must be at fault, so I unchecked them.

After rebooting the client computer, the Documents folder redirected to the Home Drive as expected.

Here’s where it gets stupid, though. On the ‘Target’ tab in the Documents properties window (visible in the screenshot above), if you have the ‘Target folder location’ set to ‘Redirect to the users home directory’, it explicitly adds a note that says “This settings ignores the value of the ‘Grant User Exclusive Rights to Documents’  option on the settings page.

Apparently not, Microsoft. Apparently not.

TL;DR Version: If Folder Redirections aren’t applying correctly, Event Viewer is showing ‘Access Denied’ messages, and you’re using Home Folders specified in the user account, disable ‘Grant User Exclusive Rights to Documents’  option on the settings page of the GPO.

• 1x Windows Server 2008 R2 with Hyper-V/AD/File Server roles, and two shared folders. Server has dual onboard NICs, one with full access to the client network below, the other to a separate network to allow the server to be managed remotely (no gateway configured on this NIC).
• 18x Windows 7 x86 clients
• Standard network setup (read: no VLANs, bridging, etc…. Just one network switch).

The previous server used by these clients worked perfectly. However, upon replacing the server with the one above, my users began noticing an odd issue. If they copy one or more files/folders to a share that is visible to all of the computers, the file(s) don’t immediately show up on all of the computers – usually 3/4 of the computers will see the file(s). On the 1/4 that don’t, users either have to wait ~10 minutes before the files will appear, or they can reboot to force a refresh. Simply pressing F5, or right-clicking in the shared folder and choosing ‘Refresh’ doesn’t work – only waiting or rebooting does.

In terms of a solution, I’ve seen a number of suggestions, but none seem to work. The server has dual-onboard Broadcom Gigabit NICs, and a number of forum posts have suggested disabling Checksum Offload and Large Send Offload, but this made no difference. Neither did disabling IPv6 on the client and server side. Disabling firewalls on the client and server side made no difference, nor did this post suggesting a few registry settings to change.

What did fix the issue, though, was disabling SMB2. Once all of the clients were connecting using the old SMB protocol the issue disappeared. I have no idea why SMB2 is an issue as I haven’t take the time to troubleshoot further with SMB2-specific settings, however this at least has things running normally.

TL;DR Version: If you have clients connecting to a Windows Server 2008 R2 box and the contents of file shares aren’t refreshing immediately or until reboot, disable SMB2 on the server.

The news, unfortunately, isn’t good. Google was little help in the case, as most of the suggestions didn’t work. The only one that did was the suggestion to rename pending.xml in C:Windowswinsxs, however this comes with a

VERY BIG,
ALL-CAPS,
RED-LETTER WARNING:

By renaming said .xml file, your server will boot. It will still briefly display the Configuring Updates message, however the login screen will appear very shortly after. The problem is that, because there are updates that have been partially installed and aborted, Windows Update is now borked (attempts to run it will only result in a 0x8000FFFF error code, which is a generic code for “Something is broken, but we don’t know what”). Based on my own experience, and that of others, there is really no way to fix it. Sorry. Microsoft KB article 946414 that suggests that this error state can be fixed by deleting the PendingXmlIdentifier value from HKEY_LOCAL_MACHINECOMPONENTS, however it doesn’t work in this case, as the entire Windows Update backend is full of half-completed operations that can’t be cleared or rolled back.

In short, if this has happened to you, I regret to inform you that your server is basically FUBAR – the only upshot of this is that as the server will now boot entirely to the desktop, and (unless something is really broken) all services should be working (note: I did have to reboot any Hyper-V virtual machines that were suspended during the reboot in order to regain network access to them). As such, you should be able to do whatever is needed to backup the server before reformatting it. Even in the event you could get Windows Update working again, I wouldn’t trust the server in a production environment.

TL;DR Version: If this happens to you, rename c:windowswinsxspending.xml using a Windows DVD to boot from, and then backup the server in prep for a reinstall.

“The requested session access is denied”

The problem, it turns out, was me. When connecting, I used a desktop shortcut for Remote Desktop Connect that had the “/admin” switch applied, which instructs Remote Desktop to connect to the Console session, which is restricted to administrators only. Using a regular shortcut without said switch solved the problem.

D’oh.

Unfortunately, when I went to download the latest version of it, 2.5, I found this notice on the download page:

ANNOUNCEMENT: Windows SteadyState will continue to be available for download through December 31, 2010. Support for Windows SteadyState will continue to be available through the Microsoft Knowledge Base portal through June 30, 2011.

This announcement does not affect your right to continue to use Windows SteadyState.

Wait, what? Further digging revealed almost no information other than a vague statement saying that SteadyState wouldn’t be updated to support Windows 7. Additionally, while the system requirements state that Windows XP SP3 is supported, there are no references to IE8 — only IE7. Even worse is the list of Windows Vista supported versions — RTM and SP1 only.

I decided to try it out on a Virtualbox VM running XP SP3 and Internet Explorer 8 (although it technically isn’t supported), as that’s what my little lab will be running, and the results were actually pretty surprising. SteadyState actually works quite well with IE8 – all of the restrictions/settings function as expected, and it’s very easy to lock everything down.

So if you’re looking for a free alternative to Deep Freeze, and running Windows XP, then SteadyState is the way to go – just make sure to grab it before December 31st of 2010, or you’re out-of-luck. If you’ve moved on to Windows 7, though, prepare to pay up for a few Deep Freeze licenses (which, to be fair, are worth the cost if you can work it in to a budget).

Update: Microsoft has published a posting on the Windows Team Blog about why SteadyState wasn’t updated for Windows 7. As some of the comments say, the whitepapers provided fall short of what most admins who use[d] SteadyState want — disk protection that isn’t available in Windows 7.

During the installation of Bootcamp, though I noticed something — Apple although Apple appears to check which model of computer you’re using for compatibility purposes, it doesn’t do the same when determining which drivers to install. As such, the installation take approximately eight-billion times longer to complete than it should (sorry, I’m no good with numbers), and leaves Programs and Features looking like this:

I mean, really Apple? Is it really that hard to add a simple WMI call (WMIC BIOS Get SMBIOSBIOSVersion, perhaps?) and compare it to a simple CSV-file and only install the drivers required for that system?

It’s a good thing they stopped making the I’m a Mac commercials, or Justin Long would need to put on fifty pounds to account for Apple’s bloat.

Background
I work for a non-profit organisation that’s primarily funded by the government. As such, we receive only a little funding for ‘technical extras’, and sadly even a cheap Class 2 SSL cert is out of financial reach at this time. The has caused a bit of a problem.

We run an Exchange 2007 server on a Windows Server 2003 box with Active Directory in along side the primary and secondary domain controllers. Our internal network was setup (by my predecessor) as foo.local. Our email, on the other hand, is hosted externally (as our ISP does not allow email servers on business accounts – go figure) on the domain mail.bar.com. Because of foo and bar, a single Class 1 Cert can’t be used – and therein lies the problem.

When I access OWA (Outlook Web App) internally, I can use the internal name of the mailserver (mail.foo.local), which uses a self-signed Class 1 Server SSL cert by the Windows Server built-in certificate authority.  Of course, when accessed externally, my browser flips out because it doesn’t recognize my own certificate authority as valid and the name on the cert itself doesn’t match (mail.foo.local compared to the external domain exchange.bar.com). Although this is technically alright, because I know enough to verify the cert manually, this confuses my users and can potentially lead to man-in-the-middle attacks.

The Solution
IIS only allows one SSL cert per Web Site. Without a Class 2 SSL cert (they allow for multiple domains to be specified) it isn’t technically possible to have two domains SSL-protected. If I apply a valid Class 1 cert for the external domain, the internal Outlook clients will throw the SSL error instead, which is much more of a problem.

Therefore, the solution is two create a second Web Site (with different port assignments, otherwise you need a second NIC and IP address) in IIS and mirror the OWA and ActiveSync Virtual Directories. This is actually easier than it sounds. Note that the following instructions are for IIS on Windows Server 2003, and Exchange 2007.

1. Open IIS, then expand the Web Sites entry.
2. Right-click on the Web Sites entry and choose “New” -> “Web Site”.
3. Choose “Next”, then give it a name (and remember it – I chose “OWA-External”), and “Next” again.
4. If you have a second NIC/IP address on the server, specify it. Otherwise, change Port 80 to an unused port (I choose 82), then click “Next”.
5. Choose a new folder to be the root of the website. It’ll stay empty, so it doesn’t matter where you put it. I created C:\inetpub2. Click “Next” again.
6. Leave the defaults selected (Read), then click “Next” and “Finish”.
7. Right click on the new website (“OWA-External” in this example”) and choose “Permissions”.
8. Add the “Internet Guest Account” for your server (typically, DOMAINIUSR_SERVERNAME) and give it Read, Read & Execute, and List permissions.
9. Click OK and close IIS.

Now that the website is setup, we need to tell Exchange to create the Virtual Directories. If you try to manually create them in IIS by mirroring the settings from the existing entries under the Default Web Site, you won’t be able to access OWA.

1. Open the Exchange Management Shell.
2. Type Get-OwaVirtualDirectory and press Enter. This will show the existing Virtual Directories.
3. Now type New-OwaVirtualDirectory -WebSiteName “OWA-External” (replacing OWA-External with your website name) and hit Enter. It make take a minute or two to process, depending on the speed/load of your server.
4. If you don’t get any errors, type Get-OwaVirtualDirectory again and you should see a new owa entry in the list.
5. Next is to create a new ActiveSync Virtual Directory in the new site. The command to do that is New-ActiveSyncVirtualDirectory -WebSiteName “OWA-External” -ExternalURL “http://exchange.bar.com/Microsoft-Server-ActiveSync” (replacing OWA-External and the URL with your own, of course).

Now open up the Exchange Management Console. Browse to Server Configuration -> Client Access. Under the Outlook Web Access and Exchange ActiveSync, you should now have two entries each – one for the original Web Site (usually Default Web Site), then one for the one you just created.

Now you’re almost done. Back in IIS, open the Properties for the new Web Site and set your SSL port to something other than 443 (unless you have two IP addresses on the server), then install your valid Class 1 SSL cert for your external domain (exchange.bar.com, in this example – I got my Class 1 cert free from www.startssl.com). The only thing left to do now is to port forward. On your router/gateway/firewall/whatever, forward port 443 to your Exchange server’s IP (or second IP if you’ve set it up that way) and, if appropriate the correct port. In my case, I forward port 443 to port 444, as well as port 444 to 444. Both are necessary if you’re using a port other than 443.

Once all this is done, restart IIS on your server and all should be ready. You’ll now have a valid cert internally and externally!