I will blog more about Deployment and PowerShell from now on.

This is my second week at Mindgrape.

I will be working more with deployment solutions like
MDT 2010/2012, SCCM 2007/2012 and scripting with PowerShell
and Windows Servers. Plus application packaging with Wise and Admin Studio.

And I will blog at least once a week.

No related posts.

I had some problems (major ones) with my local MDT 2010 last night.

After a day with lots of scripting against MDT 2010 with PowerShell my MDT 2010 installation just gave me errors when I wanted to add a new deployment share or when I wanted to open old ones:

object reference not set to an instance of an object
Microsoft.BDD.Wizards.Controls.DeploymentPointProgress.WizardProcessing

In my workbench the Deployment Shares folder was empty, no shares there. But when I looked in the user.config file I found that DS004 was in use there.

So my solution was to delete the whole file and restart the workbench.
The file can be found here, C:\Users\currentUser\AppData\Roaming\Microsoft\Microsoft Deployment Toolkit.

[Update]
DXter sent me this PowerShell oneliner after that I wrote this blog post, 

Remove-Item -Path “$ENV:USERPROFILE\AppData\Roaming\Microsoft\Microsoft Deployment Toolkit\user.config”

Thanks buddy!

No related posts.

For some time now, I have had the _SMSTSORGNAME variable in CustomSettings.ini set to “DXter’s Deployment Solution” as a display name during deployments in my home environments. However, since I do a lot of installations in my home environments, sometimes I need to know what I am actually deploying for the moment during the installation process.

One of the core strengths of MDT 2010 is its rich set of rules and variables. MDT has a lot of variables by default and one of them is %TaskSequenceName% which is a dynamic value of the name of the task sequence that is currently running.

So I thought that I should try to edit my CustomSettings.ini to tell _SMSTSORGNAME to set its value dynamic during installation based on the name of the current task sequence!

So all I hade to do was to change one line in DeploymentShare\Control\CustomSettings.ini to this:

_SMSTSORGNAME=%TaskSequenceName%

That’s it! Now lets try if it works in real life!

I select my Windows 7 Enterprise x64 task sequence that also does an online installation of the Swedish language pack.

It works like a charm! The organization name in MDT during the installation is now the name of my selected task sequence!

// Fredrik “DXter” Jonsson

P.S The Iron Man 2 background in Windows PE is NOT default in MDT 2010. D.S

No related posts.

One of my favorite features in MDT 2010 is that everything you do in the GUI is executing a PowerShell command that is using the cmd-let’s that comes with the MDT 2010 PowerShell snapin.

This gives excellent opportunities for scripting geeks such as Dalle and myself since we can automate and do exactly everything what the GUI does, since the GUI itself is using PowerShell behind the scenes.

This weekend I upgraded my private MDT environment to MDT 2010 Update 1 which was a very smooth operation. I have a very simple MDT environment at home with a single WDS/MDT server. Since I wanted to have the new and cool background picture in Windows PE that comes with Update 1, I had to update the boot images and import them to the WDS server, which in my case was on the same machine.

Therefore I created this little PowerShell script that does that for me automatically. The script is using the PowerShell cmd-let Update-MDTDeploymentShare and PS-Drive provider that comes with MDT 2010 snaping. It is also using wdsutil which is a command line based tool for managing WDS.

The script does the following tasks:

1. Generates completely new and updated boot images for your deployment share.

2. Removes you previous LiteTouch boot images from your WDS server.

3. Imports the newly created LiteTouch boot images into your WDS server.

4. Set each boot image as default boot image for respective architecture.

I must say, it works really nice.

“Do more with less…” – the PowerShell way.

The script is defaulting to MDT default names, descriptions and file locations. If you have changed any of this, please update the script according to your environment. Some people may ask why I choose to use Remove-Image and Add-Image and not Replace-Image. Well, the answer is quite simple. If I have deleted the boot image in WDS, the script would not be able to execute since there is no image to replace. If we split it up in to two commands, we will always be able to recreate our boot image in WDS regardless if the boot image is present or not, since only the Remove-Image command will fail and not the Add-Image.

So right now I have scheduled this script to run on my WDS/MDT server each midnight. If I add any new storage or NIC drivers into MDT, they will be injected automatically into the boot images during the next scheduled generation of boot images during the night and I “never” have to open the WDS console manually again!

Here is the script (don’t forget to modify it according to your installation):

Add-PSSnapIn Microsoft.BDD.PSSnapIn

New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "C:\DeploymentShare"

Update-MDTDeploymentShare -path "DS001:" -Force –Verbose

wdsutil /Remove-Image /Image:"Lite Touch Windows PE (x86)" /ImageType:Boot /Architecture:x86

wdsutil /Remove-Image /Image:"Lite Touch Windows PE (x64)" /ImageType:Boot /Architecture:x64

wdsutil /Verbose /Progress /Add-Image /ImageFile:C:\DeploymentShare\Boot\LiteTouchPE_x86.wim /ImageType:Boot

wdsutil /Verbose /Progress /Add-Image /ImageFile:C:\DeploymentShare\Boot\LiteTouchPE_x64.wim /ImageType:Boot

wdsutil /Verbose /Set-Server /BootImage:Boot\x86\images\LiteTouchPE_x86.wim /Architecture:x86

wdsutil /Verbose /Set-Server /BootImage:Boot\x64\images\LiteTouchPE_x64.wim /Architecture:x64

I must say, thank god for PowerShell!

// Fredrik “DXter” Jonsson

No related posts.

When working with MDT folders you want to sort
the folders by name to make It look better.

This is not a task you do in the Workbench.

I found a great script for this by Michael Niehaus
at Microsoft. It can be found here.

It will sort every folder in the Deployment Share structure.

The script will sort the structure by making a _TEMP_
folder and move the folder there and then move them
back sorted one by one.

You can do this manually as well in the Workbench
but It’s a big job then.

In my folder structure the comments will be deleted
this way.

If I move (copy, paste, delete old folder) a folder
in the Workbench I will get the same result.

The property “Enable this folder” seems to work just fine
with moving folders.

Is this a known bug/feature?

I will write a script that fixes this for me later on next
week. Have to do another script first

No related posts.

This is a follow up on my last blog post about
using PowerShell from a Windows 7 machine
against a MDT 2010 solution (server).

It’s a how to use the Workbench on the
Windows 7 machine to manage a MDT 2010 solution
on a remote server.

First of all you need to go in to the Workbench
and the components section.

Then select Windows Automation Installation Kit x86 or x64
and download it by push the download button. It’s a large
file ~1 GB.

And when It is downloaded, select it again (it’s now under the downloaded section) and push the install button.

Now choose Open Deployment Share on the right side of the workbench.

The path should be like \\server\deploymentshare$

Now you got the same view on your Windows 7 machine
as on the MDT 2010 server.

I love this

But I don’t love the WAIK part, 1 GB of installation to be able to
do remote administration is not so good!

No related posts.

Yesterday in my last post Always include your smart card drivers in your deployment image! I said that you should always include your mini drivers for your smart cards in your deployment image. Dalle thought that I should do a follow up with a step by step on how to do so.

Personally, I really like and use the Gemalto .NET cards. So first we go to http://catalog.update.microsoft.com/ and search for “Gemalto .NET”.

In this example we to save the cab file on my desktop.

If we take a look at my desktop, we can clearly see that I now have a new folder called "Gemalto – Input – Gemalto Minidriver for .NET Smart Card" with a cab file in it.

Now we need to prepare our cab file. We extract the content of our cab file using Windows Explorer (or WinRAR) and remove the original cab file.

Now we have our prepared driver that is ready to be injected into our WIM-file. On my desktop I have a Windows 7 Enterprise x64 WIM image. I open up DISM and mount the the image to my mount directory with the command dism /mount-wim /wimfile:install.wim /index:1 /mountdir:c:\mount

If we open up C:\mount we can clearly see that the our WIM-image has been mounted in our mount folder.

First we query our mounted WIM-file for drivers to confirm that it doesn’t have our Gemalto .NET driver with the command dism /image:c:\mount /get-drivers.

Clearly, we have only one OEM driver right now. Now lets try to add our driver using the command dism /image:c:\mount /add-driver /driver:"Gemalto – Input – Gemalto Minidriver for .NET Smart Card" /recurse. Now DISM will search that folder for any drivers and will add them to our image.

Lets try dism /image:c:\mount /get-drivers again to confirm that our driver has really been installed.

Now our Gemalto .NET driver is injected in our WIM-file! Sweet! Now all we need to do is to unmount our image and commit the changes using the command dism /unmount-wim /mountdir:c:\mount /commit.

Thats it folks! Now our image has our Gemalto.NET minidriver installed and you can straight away import the image to your WDS/MDT/SCCM deployment solution. Now when you insert your smartcard in a deployed client, it will automatically install the Gemalto.NET driver from the local driver store. Pretty cool huh?

Like Raymond Stantz in the Ghostbusters said: “Well that wasn’t such a chore now, was it?”

// Fredrik “DXter” Jonsson

No related posts.

One of the cool things in Windows 7 and Windows Server 2008 R2 is the dynamic installation of card modules through WSUS/Windows Updates. This means that if you insert a smart card into your Windows 7 box it is automatically installed through Windows Update. This is really cool and can simplify smart card installations a lot for home users and external partners.

Now people ask, what about the Gemalto .NET cards? They are using the Microsoft Base CSP and their drivers are included in Windows Vista. Yes, it is true that the Base CSP and the drivers for Gemalto .NET are included in Vista. But they are not included in Windows 7! Only the Base CSP is installed by default in Windows 7 / Windows Server 2008R2!

For a regular user, this usually is not a problem. Windows 7 can even install the necessary mini driver at the login prompt and will do so by default. But administrators may have bigger problems. Lets go through the requirements for this dynamic installation of smart cards to work:

1. The client has access to Windows Update/WSUS using the local network or internet.

2. The card is compliant with the Microsoft Base CSP and has it’s card modules available on Windows Update.

3. The system automatically installs drivers for your hardware through Windows Update (which is disable by default on Windows Server 2008 R2)

The funny thing for administrator is this: Say that you have a security policy that says that administrators can only authenticate them self using smart cards. They try to login to Windows Server 2008 R2 box and can not login since the drivers for the card are not installed and will not be installed automatically (by default). In other words, you need to authenticate with your smart card to be able to install the the mini driver for your smart card. The same thing applies if the card module is not on Windows Update or if the machine has no network or internet access to be able to install the driver.

So what happens if I add my card drivers to the driver store in my MDT/WDS solution? Won’t it be installed when the client is being installed? No. The UPNP scan only reports available hardware and install the necessary drivers for the exact hardware the client is using. If the smart card is not inserted during installation, the drivers for it will not be installed!

How do we resolve this issue? Well, if we have SCCM we can make the driver package for Gemalto .NET a mandatory package that will be installed with the operating system no matter what. If you don’t have SCCM, a very easy way to deal with this is to inject the drivers to your WIM image using offline servicing. In other words:

Always include your smart card drivers in your deployment image!

Update: A step by step guide can be found here: http://poweradmin.se/blog/2010/01/05/adding-your-smart-card-drivers-to-your-wim-image-using-offline-servicing/

// Fredrik “DXter” Jonsson

No related posts.

My good friend Fredrik “DXter” Jonsson will join
me from now on and be Co-Author for this blog.

He is one of the best I know on PKI and Ubuntu.
And he is also very good on Active Directory and
Deployment.

DXter will do a presentation of him self as fast has
he can

Welcome my friend and thank you for being my Co-Author.

No related posts.