Yes, I'm still here.

Sadly, I have neglected this blog for far too long. I am constantly reminded that I have this site due to the amount of spam comments I get. The Internet is a wonderful thing, isn't it?

Suffice to say, since my last update I have a few new things going on. I've switched jobs twice but I still love what I do. I'm excited as ever and looking forward to some new experiences. But if there is anything that I've learned in my industry it's that change is constant.

At the beginning of 2011 I moved away from ACS/Xerox and moved to Dell Services. I was part of a team named GICS, or Global Infrastructure Consulting Services. We did exactly that: consulted with companies regarding their IT infrastructure and gave advice and guidance on their current and future projects they're considering. Naturally, I specialized in OS Migrations: Windows 7 stuff. It was awesome...for the first couple weeks...

See, my team was a "national" team. That is code for travel! Awesome, right? To a certain extent. I do enjoy travel...especially when you have a company card. ;) But there was a significant toll on the family. I was traveling every week from February until the middle of July. My first stint was New York/Jersey, then Atlanta and topping it off in Dallas/Ft. Worth. From April through July I was in Texas and let me tell you...that Texas heat is something of a shocker for someone who has lived in the Pacific Northwest his entire life. And if you know me personally, you understand that my favorite seasons are Fall and Winter...not those "other two". More importantly though, it was grueling on my kids and wife. I was given some advice from someone who I trust to be mindful of travel and I'm glad he gave it to me. I didn't like the way we were heading so a change was needed.

July came and I got headhunted away to a smaller but up and coming IT consultancy. Slalom Consulting is based in Seattle, but we have a national presence. This company is AMAZING! Voted by Glassdoor.com as the 7th best company to work for! Great people, amazing relationships and opportunities and a great culture. Our next company retreat is in Whistler. I better get that snowboard out.

Hurray for awesome job???

As of December we're fully in Seattle (Issaquah really...). We're prepping our house down in Portland for rental on the weekends. Probably do this SEA to PDX thing for a couple more weekends so if anyone is interested in getting together, hit us up and let's get coffee.

Oh...that sounds good right about now.

Determine TPM State via Script

I'm currently working on another Windows 7 migration where there are several hundred laptops have TPM chips but we needed a way to determine if they were enabled and activated. Although we didn't use this solution/script I wanted to let readers know of this. This comes from Tim Mintner, one of the deployment guru's at Microsoft.

http://blogs.technet.com/b/deploymentguys/archive/2010/12/22/check-to-see-if-the-tpm-is-enabled.aspx

Deployment Resources

I've been asked to share the resources I use regarding operating system deployment (MDT/SCCM OSD) and the people I follow. Something that i've been trying to push myself lately is to give back to the community. Been a long time practitioner of leveraging community support for questions and problems I have had but really haven't been active in blog comments and forums until now.

The resources I use are blogs, forums and Twitter. Below is a list of the blogs I read on a daily basis. Thanks Google Reader!

In terms of more formal websites and forums here is what I got -

• Technet Edge
• Channel 9
• Microsoft Technet (Springboard Series)
• Microsoft Deployment Toolkit Support Forum
• Server Fault
• Deploy Vista (Not just Vista)
• Xtreme Consulting

And other engineers I follow:

• Johan Arwidmark
• Mikael Nystrom
• Chris Nackers
• Stephen L. Rose
• Michael Neihaus

There are plenty more resources I'm sure so don't expect this to be exhaustive. I'll try and keep this updated with any more resources I find.

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.

Tricky USMT, tricky…

The User State Migration Tool is part of the Windows Automated Installation Kit (WAIK) and it’s purpose is exactly that: transfer “user state” from one operating system to another. Although editing the XML can get complex, I found the Technet library reference on it very helpful and complete, or almost.

Our client had space limitations just like everyone else and to help mitigate some of these issues, we set a configuration parameter on scanstate.exe so that any Windows profiles that hadn’t been logged into in 60 days would not get captured. That flag is /UEL:60.

At the same time, we didn’t want certain profiles to be captured either…say for instance the local Administrator account. So for this we specified /UE:%COMPUTERNAME%\Administrator on the scanstate.exe command line as well.

I won’t go into extreme detail, but in short this does not work. USMT has specific rules of precedence depending on the switches and they don’t always merge. If you use the UEL and you specify an UE exclusion, if that UE exclusion has logged in within 60 days that profile will get captured. UEL will take precedence. You can get around this in your deployment by creating a task sequence step to run a tool to remove unwanted profiles before you perform a USMT capture. Check the references section for a blog entry describing this in more detail and a reference on USMT ScanState tool.

This caused my team headaches and I hope this helps other engineers so they don’t have to self medicate as much as I did in their deployments.