That’s one heck of a long post title, but it at least describes the issue. Here’s the setup:

  • 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.

Yesterday, while running a large lump of Windows Updates, one of my Windows Server 2008 x64 boxen decided to start boot-looping in the most annoying way. After applying a group of around ten updates and restarting, the server rebooted to the Welcome Screen and hung on the message “Please wait for the Windows Modules Installer” before eventually giving up and rebooting. After that, it booted back to the Welcome Screen and this time displayed the “Configuring Updates Stage 3 of 3 0%” message. All was well, I thought, until two minutes later when the screen went black and the server (gracefully) rebooted again, and then proceeded to loop under the same conditions, regardless of which startup mode is selected (Safe Mode, Last Known Good Configuration Mode, etc… will all produce the same results).

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.

I was trying to assist another admin with a login issue on a Windows Server 2008 terminal server when I encountered a slightly different login error than the one he was describing. When attempting to connect to the terminal server with a user not in the Domain Administrators security group I received the following message:

“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.

I’ve only used Microsoft SteadyState a few times, but it’s a great product if you can’t afford the per-seat licenses for Faronics Deep Freeze. So when I was given the task of putting together a small lab environment with old computers and no funding, SteadyState was the first thing that came to mind.

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.

I came back from vacation the other day to find that some computers on our primary domain (example.local) were unable to access shares on a secondary domain (test.local) located in another building, accessed via a wireless link). When attempting to open the share (or just browse to the Domain Controller), the following error would appear:

Share Error

"There are currently no logon servers available to service the logon request."

Google’ing did no good, as there were only vague references to DNS issues and WINS servers (the later of which we don’t use). As nothing had changed in the environment recently, I was at a bit of a loss. I could ping the DC (Homer) in question, and even RDP to it, but I couldn’t for the life of me access the share. NSLOOKUP behaved normally, but then I had a thought — the DC that I couldn’t access was also acting as a DNS server (the primary one for test.local) with example.local as a Secondary Zone (which, of course, contained the DNS entries for the computers that were having trouble accessing the secondary domain). When I loaded the DNS manager and clicked on that zone, I was immediately greeted with an error stating the following:

DNS Error

Turns out, there *was* a DNS problem!

The problem was that I had removed a DNS server over a year ago and it was still referenced as the primary DNS server for this zone. For some reason, the Windows DNS service had just now decided this was a problem and stopped grabbing copies of the zone from the functional secondary DNS server.

To fix this, I simply right-clicked on the zone, chose Properties, and then removed the offending server IP from the General tab and updated with the correct servers and order. As soon as I finished, the computers had no trouble accessing that DC again. Magic!

I received an email today welcoming me to the Microsoft Security Essentials beta (which is odd, as I’ve been in the MSE beta since it was first launched), as the following paragraph jumped out at me as I skimmed it:

Notice to Windows® Home Server customers: Microsoft Security Essentials Beta is not supported on Windows Home Server (WHS). Beta testers who have installed Microsoft Security Essentials Beta on WHS should consider uninstalling Microsoft Security Essentials Beta to avoid potential incompatibility problems. Those who plan to beta test Microsoft Security Essentials Beta unsupported on WHS should wait until the next Windows Home Server update rollup currently scheduled to occur on or about September 1, 2010.

Emphasis mine. It’s not a lot to go on, but Microsoft may finally be officially adding support for their own anti-virus product to Windows Home Server. In the words of Jeremy Clarkson, “Sweeeeeeeeeeeeeeeeeeet!”

Yes, it is possible. It’s not pretty by any means (a proper Class 2 SSL Certificate is the best way to go), but it can be done. Click Continue Reading for the process.

More »

Microsoft Security EssentialsI downloaded the Microsoft Security Essentials Ongoing Beta from Microsoft Connect this evening, and as before it installed normally. However, when I tried to update it to the latest version (the setup file on Connect is very out-of-date) the definitions came in fine but the core product refused to upgrade and only provided the error code 0×80070050.

Event viewer wasn’t helpful, a reboot didn’t fix it, and neither did uninstalling/reinstalling. On a whim, though, I decided to try to the upgrade through Windows Update (after enabling Microsoft Update) and what do you know, it worked!

TL;DR Version: If you get the 0×80070050 error code while trying to upgrade MSE through the MSE program itself, enable Microsoft Update via the Windows Update Control Panel and do the upgrade from there.

When Valve was first leaking details about Steam for Mac, they released a series of images parodying ‘classic’ Apple ads. This was one:

Turrets

I get what they’re trying to say – the PC is boxy and old-fashioned while the Mac is shiny and new. The unintentional humour is that while the Portal turret does it’s job adequately in its game, it’s easily defeated. The PC (or Team Fortress 2 turret) on the other hand starts out small and meek, but can be easily upgraded in to a massive powerhouse. That said, which would you rather have? Effective but locked down, or less-than-pretty but easily customizable?

Of course, I could just be reading too much in to things again.

According to a letter I received in the mail today (I had no idea people still used ‘letters’ for communication anymore), Microsoft is launching a new ‘Canadian Open License for Government’ program.

Letter from Microsoft Canada

The Post-It Note is for my own protection - click for a larger view

Details are rather scarce at the moment. The letter indicates that more information is available from http://www.microsoft.ca/licensing, but there isn’t even a full article present, just the following text:

Government Open License Program Announcement
On June 1st, 2010, Microsoft is launching the Government Open License program in Canada, which will reduce the cost of Open Licenses for Government organizations by approximately 20 percent. This new Volume License Program will also provide flexibility to Canadian Government organizations as customers will now have a viable option to procure licenses from their reseller of choice at competitive prices.

Eligibility
With an initial purchase of five or more licenses, customers can acquire products as needed over the term of their agreement. Government organizations will also have to meet the eligibility definition requirements in order to qualify for the Government Open License Program: English – French.

For more information, or to find a Microsoft reseller near you, call the Microsoft Resource Centre at (877) 568-2495.

I called the number listed, and the lady I spoke with said that she had information that was passed to her, but she was unsure if she was allowed to give it out. What did tell me wasn’t any different than what the text above said – qualifying Government organizations (definitions of ‘qualifying’ vary depending on if you are part of the government or how much funding you receive if you’re a contractor).

So in short, if you meet Microsoft’s definition of a Government organization in Canada, you can now obtain software at a 20% discount.