Auto Removal of MDT State Folders

When you're building and testing MDT deployments as often as I do, you appreciate scripting and automation. Often times, I'm wiping and kicking off deployments within WinPE. You hit go, wait awhile and then you find something that needs to be modified either in the image or part of the task sequence. You make the change in MDT and...

You need to retest.

So you restart the PC (or VM in many of my scenarios) and boot back into WinPE. You expect to find the Welcome to Windows Deployment wizard but instead you find an error message indicating that the installation cannot continue due to the fact that it is in WinPE. What is happening?

In order to maintain deployment state across reboots, the task sequencer writes variables and logs in two specific locations: %SYSTEMDRIVE%\_SMSTSequence and also %SYSTEMDRIVE%\MININT. When WinPE boots, it looks in these locations to see if there is any information it needs. Problem is, most of the time when you're entering into WinPE you're there to wipe and reload the OS, not to continue OS installation. What needs to happen, in the words of Johan Arwidmark is to "get rid of the junk".

What we want to do is remove these folders before the Deployment Wizard discovers them and throws an error. You can add a command script to the Unattend.xml of WinPE inside the RunSynchonous element. The command script would perform something like this:

If Exist C:\MININT\nul rd C:\MININT /s /q
If Exist C:\_SMSTaskSequence\nul rd C:\_SMSTaskSequence /s /q

Check out the reference below to read more about this and also check out Johan's other blog post's at http://www.deployvista.com. He has some great content.

Replacement Mode of an EBS Server

This weekend I will be performing a wipe and load of an EBS Management server. Last month I picked up the Windows Essential Business Server 2008 Administrator's Companion book and I must say, I'm pretty happy with it.

The book is more of a mid-level overview of the process and procedures on how to do things within EBS. Lately I've been diving into the certification books so this was refreshing to have a broader product outlook. It does provide steps on how to accomplish certain procedures like a replacement mode installation, but most people who know me understand that I like detail as well.

A replacement mode installation is just what it sounds: the replacement of an EBS server role. In my case, its the Management server. You can use this installation mode when you upgrade a servers hardware or need to start from a clean installation but maintain your EBS configuration. One of the very cool aspects of EBS is that it stores the configuration of that EBS implementation inside Active Directory.

For those who haven't configured EBS yet, there are two wizards that need to be ran before integrating EBS into your environment. The Preparation Wizard and the Planning Wizard both gather information about your network and how to configure the server and store it inside AD. If a replacement mode installation is detected, WEBS Setup will use that information for self configuration. This is also how it determines that it's in replacement mode, the fact that the MMSConfiguration object exists in Active Directory.

I should remind people that replacement mode installation does not restore data, just the server and configuration into an operational state. You will need to restore user data from backups.

Hope this gives you a little insight on the replacement mode installation for EBS.

SQL Reporting Services SP3 Installation Woes

While I was supporting a client I came across an issue where one of the updates failed on the Management server in an EBS installation. Maybe failed is the wrong term to use as the update reported that it would install successfully, but the next day or so (or if you manually kick of the detection logic) that update would reappear. Strange.

Looks like this is a known issue. The update in question is the SQL Server 2005 with Advanced Services SP3 (KB955706). Turns out that on my specific installation, it had upgraded the SQL Database instance but the Reporting Services instance hadn't been updated to SP3. This is why the update is re-offered. When I attempted to install the update manually, it would stop me indicating that none of the components were able to be upgraded.

As I said before, it was a known issue. The fine folks on the EBS Team Blog have an article about it here, and my problem was resolved successfully. But why does this happen?

I was curious.

Turns out, when you launch the update, it runs the Best Practices Analyzer and notices that the ASP.NET version enabled on IIS does not allow 32-bit application pools. This is a problem as the service pack needs this enabled to upgrade the reporting services instance. It is important to remember to change this back though, as applications will use 32-bit ASP.NET and not the native 64-bit bits. Since the EBS Admin Console likes 64-bit if you don't change this setting back your console will crash.

MS Employee Answers Important Questions

I saw this on Reddit today and got a chuckle out of it. Dude asking MS employee some questions...  

Windows Recovery Environment (WinRE)

I’ve been a fan of WinPE since the introduction of BartPE. In the next stage of Windows with both Windows Vista, Windows Server 2008, Windows 7 and Windows 2008 R2 it uses a revamped version of WinPE. What’s even better is that the Windows Recovery Environment (WinRE) is based upon the new WinPE image.

Instead of me giving you an overview of it though, I would like to direct you to someone who is MUCH more knowledgeable in it and has done significant research/study into this great technology. Check out Sean Kearney of Energized Tech. You can read his series “WinRE – Windows Recovery Environment” as its filled with great information on making your own recovery environment. You can also follow him on twitter.

Clubhouse Tags: microsoft, winre, winpe