Dalle & DXter

Automated boot image management in MDT 2010 and WDS using PowerShell

By Fredrik "DXter" Jonsson

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

PKI View is no longer a supported way for CA decommission

By Fredrik "DXter" Jonsson

Thanks to my post http://poweradmin.se/blog/2010/05/08/pkiview-msc-doesnt-say-the-entire-truth and the great, open and quick communication between myself and Microsoft, PKI View is no longer a part of KB889250, which is the step by step guide for CA decommission. I really salute Microsoft for listening to the communities (such as blogs ) and removes references in KB’s that have unexpected behaviors and may cause confusion for people! Kudos to you guys!

 

I guess it is back to hardcore, old school stuff again with ldifde.exe, dssite.msc and adsiedit.msc when it comes to CA decommissions, which is just fine with me!

 

Who knows? Maybe two guys will make a very nice PowerShell based GUI for managing the Public Key Services container using the Cmd-Lets for Active Directory in Windows Server 2008 R2? Time will tell…

 

// Fredrik “DXter” Jonsson

Pkiview.msc doesn’t say the entire truth…

By Fredrik "DXter" Jonsson

I guess I am not the only one that usually removes old PKI stuff from the Public Key Container in Active Directory with pkiview.msc.

 

However, recently I discovered something that kind of bothered me. I was working with a customer of mine, and I was removing some stuff in sites and services regarding a decommissioned DC and I by curiosity open the Public Key Services container to take a look at it. I found three objects in the KRA Container and I decided to take a look at them with pkiview.msc since it presents PKI related objects in Active Directory in a much nice way than Sites and Services. But you can imagine my face expression when pkiview.msc reported the container as empty!

 

As you guys must understand, I just had to reproduce this “bug”.

 

So this morning, I installed a virtual Windows Server 2008 R2 Standard Edition in a isolated environment and made it a DC for the domain wtf.poweradmin.se.

 

I also made it an Enterprise Root CA for the same domain. After that, I started by confirming that the KRA object was located in that container. There are multiple ways to look at the PKI information in Active Directory but I decided to use five of them for this test.

 

I started with adsiedit.msc:

ADSI Edit clearly shows that we have a object in the KRA container.

 

 

Then I decided to try dssite.msc:

Sites and Services also displays our object in the KRA container (if we show services nodes).

 

 

A third option is to use a LDAP using ldifde:

It writes out entries to a text file, and if we look at that text file…

 

 

… we can actually see the same info that both ADSI Edit and Sites And Services has provided us earlier.

 

 

Our fourth option is to query Active Directory with the Active Directory Module for PowerShell:

PowerShell also shows us our object in the KRA container.

 

 

Now, what does the fifth option, pkiview.msc, say about the KRA container? Well…

… according to Manage AD Containers in PKI View, the KRA Container is empty.

 

I recommend you guys that have removed objects of decommissioned CA’s with the “Manage AD containers” in PKI View: Look again in the KRA Container with ADSI Edit, Sites And Services, LDAP or PowerShell. You might find something interesting left behind.

 

Update: http://poweradmin.se/blog/2010/06/02/pki-view-is-no-longer-a-supported-way-for-ca-decommission/

 

// Fredrik “DXter” Jonsson

Revealing your WLAN password using netsh and PowerShell

By Fredrik "DXter" Jonsson

I have for a very long time tried to explain to people that network security using pre shared keys is a false feeling of security (you should look at PKI based solutions instead )! Many people seems to think that you must have one of those evil hacking tools (that your antivirus probably will detect) to be able to get your password for your WLAN from your computer in a clear text format. But that is incorrect, we can actually do this with built in tools in Windows.

 

For example, the following one liner is using netsh to reveal your WLAN password and is using PowerShell to sort out the security information and dumps it into a text file in the folder that your are executing the command. This command should be executed in an elevated PowerShell prompt.

 

netsh wlan show profiles name="the_name_of_your_network_profile_which_is_usually_the_ssid" key=clear | Select-Object -last 8 | Out-File -Filepath .\wlan_security_settings.txt

 

// Fredrik “DXter” Jonsson

Three ways to kill and avoid KB976002 (The Microsoft Browser Choice Screen)

By Fredrik "DXter" Jonsson

I am not a very big fan of KB976002, the Microsoft Browser Choice Screen. Here are three ways to prevent it to appear on your computers:

 

1. The cmd way:

reg add HKLM\Software\BrowserChoice /v Enable /t REG_DWORD /d 0×00000000 /f

 

 

2. The VB.NET way:

Public Module Registry
Public Sub Main()

My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\Software\BrowserChoice", "Enable", "0", Microsoft.Win32.RegistryValueKind.DWord)

End Sub
End Module

 

 

3. The PowerShell way:

Set-ItemProperty -path ‘HKLM:\Software\BrowserChoice’ -name ‘Enable’ -type ‘DWord’ -value ‘0‘

 

 

An interesting fact however is that KB976002 can not yet be found in WSUS. I wonder if it will ever show up?

 

 

// Fredrik “DXter” Jonsson

The story continues

By Fredrik Wall

Hi,

I sat down thinking a little bit today.
And then It strikes me that the Lab AD was not finished
and that It was not done by best practice.

So I will do the structure from this document from Microsoft,
Best Practice Active Directory Design for Managing Windows Networks.

And then we need to:

1. Create groups
2. Computers
3. OU Information

Then I think we are where we should be.

 

Code signing using PowerShell

By Fredrik "DXter" Jonsson

In my last post Creating your own code signing certificate on a smartcard without an internal PKI, I showed the process to create a self signed code signing certificate on a smartcard. Since PowerShell has the ability to check signatures of PowerShell files before they are executed, signed PowerShell files are preferred for obvious security reasons.

 

First we can check what code signing certificates we have using the PowerShell command:

Get-ChildItem -Path cert:\CurrentUser\my –CodeSigningCert

which in my case gives the following output:

I see the code signing certificate that I have to sign our tools for PKI ToolBox. This certificate is located on a Gemalto .NET smartcard.

Now we can build a code signing script using the PowerShell cmd-let Set-AuthenticodeSignature.

 

The following code is the actual PowerShell signing script that we use to sign our tools in the PKI ToolBox:

$cert=Get-ChildItem -Path cert:\CurrentUser\My\F1BF8F3ABBD6295D77C8D4BD6FEEDC19E32A9A74
$cue=Get-ChildItem .\cue
Set-Location .\cue
Set-AuthenticodeSignature -FilePath $cue -certificate $cert -IncludeChain All -TimeStampServer "http://timestamp.verisign.com/scripts/timstamp.dll" 
Set-Location ..

 

1. The first thing we do is to create a folder called cue in the same location that the script is located. In this folder we put our PowerShell files that will be signed.

2. We specify a variable called $cert that is our code signing certificate. The reason I am not using the flag –CodeSigningCert when i call Get-ChildItem is because I want to be specific about which exact certificate we want to use for our digital signature, using the signing certificates exact thumbprint.

3. We create a variable called $cue that is equal to all objects in the cue folder. The reason we don’t want to use a hard coded reference to a target file is because the signature for the signing script itself will be broken if we modify the script and specify another file.

4. We jump into the folder cue and try to get all child objects in the current cue folder, resulting back in a list of PowerShell files that will be signed by our script. Pretty cool huh?

5. The cmd-let Set-AuthenticodeSignature is signing all our files in the cue folder with our specified certificate on our smartcard (the script is prompting for the user for PIN to the smartcard). Since the timestamp on the signed PowerShell file is the actual time of the signing computer, this may not be so reliable to decide the actual singing time. Therefore we also include a countersignature from VeriSign’s timestamp server with the flag –TimeStampServer “http://timestamp.verisign.com/scripts/timstamp.dll” to convince our users that the timestamp is reliable.

 

Now, lets look at the result of a signed PowerShell file:

First we see that we have a new tab under the files properties, called “Digital Signatures”

 

 

 

If we look at the details, we se that our digital signature is OK and that VeriSign has confirmed our signature date and time.

 

 

 

A video of this is already done by me and Dalle when we visited Microsoft last Friday to record our demo of PKI ToolBox for TechNet Edge. The video will be posted on http://edge.technet.com in the near future.

 

// Fredrik ”DXter” Jonsson

Use Active Directory PowerShell to manage win 2003-2008 DCs

By Fredrik Wall

Microsoft have been working on a solution for us to be able to use the AD PowerShell cmdlets to manage 2003 DCs too.

http://blogs.msdn.com/adpowershell/archive/2009/06/23/use-active-directory-powershell-to-manage-windows-2003-2008-dcs.aspx

Very nice!