May, 2009

A couple of weeks ago at the Microsoft Management Summit conference in Las Vegas, I demonstrated some PowerShell scripts for doing a variety of things.  I had promised to post those to my blog so that you could use them as well.  This is the first of those scripts, designed to help maintain the contents of the MDT database.  I have done some additional work on this one since I demonstrated it, and it’s now ready for your enjoyment.

This PowerShell script leverages the PowerShell 2.0 “advanced function” capabilities to write PowerShell cmdlets using PowerShell scripts – no compiled code is required.  That does mean that you must be running PowerShell 2.0 CTP3 or later (e.g. the version of PowerShell included in Windows 7).  There is no dependency on a particular version of MDT, so you can use this with MDT 2008, MDT 2010, or even BDD 2007 if you so choose.

The script files themselves are rather bare – lots of scripts, very few comments, and no documentation at all beyond what is in this blog post.  There just aren’t enough hours in the day to do those types of things.  It’s bad enough that the PowerShell module script has already grown to over 1,500 lines.

Here’s the quick list of Cmdlets included in the MDTDB.psm1 script and a very brief description of each:

1. Connect-MDTDatabase.  Establish a connection to an MDT database.
2. New-MDTComputer.  Create a new computer entry.
3. Get-MDTComputer.  Get an existing computer entry, or a list of all computer entries.
4. Set-MDTComputer.  Modify the settings of an existing computer entry.
5. Remove-MDTComputer.  Remove an existing computer entry.
6. Get-MDTComputerApplication.  Get the applications for an existing computer entry.
7. Clear-MDTComputerApplication.  Remove all applications from an existing computer entry.
8. Set-MDTComputerApplication.  Modify the list of applications for an existing computer entry.
9. Get-MDTComputerPackage.  Get the ConfigMgr packages for an existing computer entry.
10. Clear-MDTComputerPackage.  Remove all packages from an existing computer entry.
11. Set-MDTComputerPackage.  Modify the list of packages for an existing computer entry.
12. Get-MDTComputerRole.  Get the list of roles for an existing computer entry.
13. Clear-MDTComputerRole.  Remove all roles from an existing computer entry.
14. Set-MDTComputerRole.  Modify the list of roles for an existing computer entry.
15. Get-MDTComputerAdministrator.  Get the list of administrators for an existing computer entry.
16. Clear-MDTComputerAdministrator.  Remove all administrators from an existing computer entry.
17. Set-MDTComputerAdministrator.  Modify the list of administrators for an existing computer entry.
18. New-MDTRole.  Create a new role.
19. Get-MDTRole.  Get an existing role, or a list of all roles.
20. Set-MDTRole.  Modify the settings of an existing role.
21. Remove-MDTRole.  Remove an existing role.
22. Get-MDTRoleApplication.  Get the applications for an existing role.
23. Clear-MDTRoleApplication.  Remove all applications from an existing role.
24. Set-MDTRoleApplication.  Modify the list of application for an existing role.
25. Get-MDTRolePackage.  Get the ConfigMgr packages for an existing role.
26. Clear-MDTRolePackage.  Remove all packages from an existing role.
27. Set-MDTRolePackage.  Modify the list of packages for an existing role.
28. Get-MDTRoleRole.  Get the list of roles for an existing role.
29. Clear-MDTRoleRole.  Remove all roles from an existing role.
30. Set-MDTRoleRole.  Modify the list of roles for an existing role.
31. Get-MDTRoleAdministrator.  Get the list of administrators for an existing role.
32. Clear-MDTRoleAdministrator.  Remove all administrators from an existing role.
33. Set-MDTRoleAdministrator.  Modify the list of administrators for an existing role.
34. New-MDTLocation.  Create a new location.
35. Get-MDTLocation.  Get an existing location, or a list of locations.
36. Set-MDTLocation.  Modify the settings of an existing location.
37. Remove-MDTLocation.  Remove an existing location.
38. Get-MDTLocationApplication.  Get the applications for an existing location.
39. Clear-MDTLocationApplication.  Remove all applications from an existing location.
40. Set-MDTLocationApplication.  Modify the list of applications for an existing location.
41. Get-MDTLocationPackage.  Get the ConfigMgr packages for an existing location.
42. Clear-MDTLocationPackage.  Remove all packages from an existing location.
43. Set-MDTLocationPackage.  Modify the list of packages for an existing location.
44. Get-MDTLocationRole.  Get the roles for an existing location.
45. Clear-MDTLocationRole.  Remove all roles from an existing location.
46. Set-MDTLocationRole.  Modify the list of roles for an existing location.
47. Get-MDTLocationAdministrator.  Get the administrators for an existing location.
48. Clear-MDTLocationAdministrator.  Remove all administrators from an existing location.
49. Set-MDTLocationAdministrator. 
50. New-MDTMakeModel
51. Get-MDTMakeModel
52. Set-MDTMakeModel
53. Remove-MDTMakeModel
54. Get-MDTMakeModelApplication
55. Clear-MDTMakeModelApplication
56. Set-MDTMakeModelApplication
57. Get-MDTMakeModelPackage
58. Clear-MDTMakeModelPackage
59. Set-MDTMakeModelPackage
60. Get-MDTMakeModelRole
61. Clear-MDTMakeModelRole
62. Set-MDTMakeModelRole
63. Get-MDTMakeModelAdministrator
64. Clear-MDTMakeModelAdministrator
65. Set-MDTMakeModelAdministrator
66. New-MDTPackageMapping
67. Get-MDTPackageMapping
68. Set-MDTPackageMapping
69. Remove-MDTPackageMapping

Yes, there really are 69 different cmdlets in the script.  I could have tried generalizing some of these, but then you’d have to provide more parameters to each one, so this actually simplifies things a little.  A few notes:

• Connect-MDTDatabase can connect in two ways.  One way works with MDT 2010 Beta 1 or earlier, where you have to specify the connection details (server, instance, database name).  The other works with MDT 2010 Beta 2 or later, where you can just point to the deployment share that contains all the needed details.
• Only the “Get” cmdlets are used to select items by some identifier (e.g. MAC address).  The other commands use the ID.  So the standard process will be to use “Get” with the other cmdlets in the same pipeline.
• The settings are specified using a hash table.  See http://www.microsoft.com/technet/scriptcenter/resources/pstips/sept07/pstip0914.mspx for details.  An example for MDT might be @{SkipWizard=’YES’;DoCapture=’TRUE’}.
• Lists are specified using an array.  See http://blogs.msdn.com/powershell/archive/2007/01/23/array-literals-in-powershell.aspx for samples.  An MDT-specific example might be @(‘10.1.1.1’,’10.1.2.1’, ‘10.1.3.1’).
• You may not have any need to call the “Clear” cmdlets, but they are used behind the scenes by the “Set” cmdlets.
• Get-MDTLocation behaves a little differently than the other “Get” cmdlets.  This is because it would otherwise return one location item per default gateway, and that would mess up the other cmdlets.  So by default, Get-MDTLocation will only return the location name and ID (single record).  If you want to see the settings and list of gateways, add “-detail” to the PowerShell command.
• In most cases, parameters can be retrieved from the pipeline.  This lets you do some interesting batch processes.

So how do you use all of these?  See the included “MDTDB_Test.ps1” script for some simple examples (used to test the logic).  Here are a few more examples, just to give you some ideas.

Create a new computer and set its details

To add a new computer, just specify some identifying details (at least a MAC address, serial number, asset tag, or UUID, or any combination of those), along with whatever settings you want to configure.  This example adds a machine, specifies its settings, and configures it with a list of applications:

import-module .\MDTDB.psm1
connect-mdtdatabase -sqlserver MNiehaus-T61P-7 -instance SQLEXPRESS -database MDTDatabase
new-mdtcomputer -macAddress '00:00:00:11:22:33' -settings @{OSInstall='YES'; OSDComputerName='MYPC'}
get-mdtcomputer -macaddress '00:00:00:11:22:33' | Set-MDTComputerApplication -applications @('{dc83b044-f018-40ec-828f-5e2b77058bb4}','{e7d31704-af9d-4105-ad4b-dbb95e23b692}')

You could actually shorten this too, since New-MDTComputer returns the new item which can be piped into Set-MDTComputerApplication:

import-module .\MDTDB.psm1
connect-mdtdatabase -sqlserver MNiehaus-T61P-7 -instance SQLEXPRESS -database MDTDatabase
new-mdtcomputer -macAddress '00:00:00:11:22:33' -settings @{OSInstall='YES'; OSDComputerName='MYPC'} | Set-MDTComputerApplication -applications @('{dc83b044-f018-40ec-828f-5e2b77058bb4}','{e7d31704-af9d-4105-ad4b-dbb95e23b692}')

Import a list of makes and models

Assume you have a “Models.csv” file that looks like this (maybe exported from ConfigMgr):

Make,Model
Dell,Latitude e6400
Lenovo,T61p
HP,dx5150
Toshiba,M400

With that, you can then issue a simple PowerShell command to quickly create multiple MDT database entries:

import-module .\MDTDB.psm1
connect-mdtdatabase -sqlserver MNiehaus-T61P-7 -instance SQLEXPRESS -database MDTDatabase
import-csv .\Models.csv | New-MDTMakeModel -settings @{OSInstall='YES'}

Create a new role and set its details

Creating a new role just requires specifying its name, along with any settings you want.  In this case, I’ll also add a list of ConfigMgr packages that should be installed with this role:

import-module .\MDTDB.psm1
connect-mdtdatabase -sqlserver MNiehaus-T61P-7 -instance SQLEXPRESS -database MDTDatabase
New-MDTRole -name 'My Role' -settings @{Home_Page = 'http://www.live.com'} | Set-MDTRolePackage -packages @('XXX00001:Install','XXX00002:Install')

List all contents

The “get” cmdlets can be used to retrieve a list of existing items by not specifying any criteria:

import-module .\MDTDB.psm1
connect-mdtdatabase -sqlserver MNiehaus-T61P-7 -instance SQLEXPRESS -database MDTDatabase
Get-MDTComputer
Get-MDTLocation
Get-MDTMakeModel
Get-MDTRole

Note that you might want to specify -detail on the Get-MDTLocation cmdlet to get the details; this will cause it to return one row per gateway value.

Add a package mapping entry

MDT provides a sample table and stored procedure for reinstalling software on a computer based on ConfigMgr inventory.  To support this, you need to populate the package mapping table with entries to indicate which package should be installed for machine with a particular Add/Remove Programs entry.  Adding an entry can be done fairly easily:

import-module .\MDTDB.psm1
connect-mdtdatabase -sqlserver MNiehaus-T61P-7 -instance SQLEXPRESS -database MDTDatabase
New-MDTPackageMapping -ARPName 'Zune' -package 'XXX00003:Install'

For those of you who attended my driver management sessions at MMS 2009 and TechEd 2009 US, you know that Dell is planning to provide CAB files for many of their machines, starting with the corporate laptop models.  These are “raw” drivers, provided in a CAB file that saves you the hassle of trying to figure out how to download and extract the contents of dozens of different packages for each model.  Now, one CAB file contains all the files you need, just extract the contents of the CAB and import them into your driver repository of choice (MDT 2008, MDT 2010, ConfigMgr, WDS R2, etc.).

See http://www.delltechcenter.com/page/Dell+Business+Client+Operating+System+Deployment+-+The+.CAB+Files for the list of models that now have CAB files posted (there are quite a few).

Once MDT 2010 Beta 2 comes out, you won’t even need to extract the contents of the CAB files.  Deployment Workbench will automatically extract the CAB file contents into a temporary folder and then import each driver that it finds.

There was a fix released back in September that got ConfigMgr 2007 working with SQL Server 2008, http://support.microsoft.com/kb/955229.  I also had a post earlier today, ConfigMgr hotfix for driver issues when using SQL Server 2008, to address driver issues.

Now today I see that there is another new SQL Server 2008-related hotfix for ConfigMgr, this one fixing problems introduced by the original fix, KB 955229.

So if you are using SQL Server 2008, please check these out.  With any luck all of these fixes will be in ConfigMgr 2007 SP2, with the beta of that due out in the coming weeks.  Since that will add full support for Windows 7 deployment, that’s what you all really need anyway :-)

This week at TechEd, Tim Mintner, Rhonda Layfield, Mikael Nystrom, Johan Arwidmark, Jeremy Chapman, and I participated in a Springboard panel discussion hosted by Stephen Rose talking about Windows 7 and related Windows deployment.  You can watch the video at http://www.msteched.com/online/view.aspx?tid=472e8bf1-6dfa-4644-b323-13737c32a784.  (I just can’t bring myself to watch it to tell you how well we did – it’s too hard to watch myself…)

I installed the Windows Virtual PC and XP Mode betas on my laptop running Windows 7 RC.  If you haven’t tried it yet, you can download the pieces (both of them) from http://www.microsoft.com/windows/virtual-pc/download.aspx.  The installation process is pretty simple (one MSU, a reboot, and an MSI).  Once you are done, you can start up the pre-build Windows XP virtual machine.  Once it is up and running, install any software you want, copy some shortcuts to the “All Users” start menu programs folder, and then close the virtual machine window.  This will hibernate the VM.

Notice then that the shortcuts copied to the “All Users” start menu now show up in a folder on your start menu (Programs –> Windows Virtual PC –> Virtual Windows XP Applications).  When you choose one of those shortcuts, the VM is automatically restarted and the application starts – seamlessly, without you even knowing it is running in a VM.

Since I didn’t have any applications handy, I just copied the “Internet Explorer” icon so that I could run IE 6 from my Windows 7 machine.  It’s really freaky to see IE 6 and IE 8 running side-by-side:

Very nice.  Just make sure you are using machines that support Intel VT or AMD-V – required for the new Virtual PC to work.

A new KB article, http://support.microsoft.com/kb/955262, was posted recently with a fix for issues you may encounter when dealing with drivers if your site server is using SQL Server 2008.  Be sure to read the details in the KB article closely, as you need to deploy this hotfix to each of the admin consoles in your environment.

It’s also interesting that the article says this will overwrite AdminConsole.xml causing you to lose any modifications – even though modifications would be unsupported…

It also appears that this hotfix won’t install on a Windows Server 2008 SP2 machine, but hopefully that problem will be fixed soon.