May 2010 - Posts
The information in this post is provided as-is, please use at your own risk and test appropriately.
Been meaning to create a post on this for quite some time. I just want to cover the basic setup of the Deployment Web Service created by Maik Koster. The latest download can be located here. (V7 as of this posting) There is some documentation on the Codeplex site, and i urge you to review that as well. CodePlex Documentation. If you are going to be using the MDT functions of the web service, then you need to configure the Stored Procedures as well, and I recommend you read Maik's blog post on this topic as i won’t be covering that in this post.
This will just be a quick-start guide for Server 2003 and IIS 6. So lets get started!
1) First download the files from the site linked above.
2) Extract out the web service files into a directory of your choosing, I still like to put items in Inetpub if it’s IIS related. So \Inetpub\DeploymentWebService in my case.
3) Next we need to create a Virtual Directory in IIS.
Right-Click on Default Web-Site and select New – Virtual Directory
Next
Name the Virtual Directory and click Next
Browse to the path of the files you extracted
Select Next
Make sure to check “Read” and “Run Scripts”, then click Next
Click Finish
4) Next we need to setup the Application Pool, I generally like to create a separate pool so you can recycle the pool without effecting anything else you might have running on that IIS server.
Right-click on Applications Pools and select New – Application Pool
Name the Web Pool appropriately, then click OK
Next we want to configure the identity of the web pool, here you can select the account that will run the Web Pool, most people will use a service account and specify those credentials here, this account will be the default account the web service is running under, so it will need rights to perform the web service functions you want to use:
5) Next we need to setup the Web Service to use the new Pool:
Go into the properties of the Virtual Directory you created and change the Application Pool to the web pool you previously created (MDTWebPool in screenshot):
You’ll also want to make sure under the ASP.NET tab that ASP.NET versions 2.0 is selected:
6) Next we need to configure the web service settings in the web.config (this step copied from Maik’s documentation)
On default, the webservice will use the configured application pool user for authentication. It requires only a couple Application Settings to be set:
- RootServer - The SCCM Root Server
- SLPServer - One SCCM Server with the SLP Role
- RootSiteCode - The Root site code
For Access to the MDT Database you need to configure at least
- MDTDBServer - The MDT Database server (with Instance if necessary)
- MDTDBName - The MDT Database name
- MDTDBIntegratedSecurity - Set to "True" if you want to use the application pool account for authentication. If set to "False" you need to supply the following two settings
- MDTDBUser - Username to access the MDT Database
- MDTDBPassword - Password to access the MDT Database
For Active Directory access, you can optionally configure the following Application Settings. This is only necessary, if the application pool user account does not have enough permissions to do execute the required functions, and/or if you need to access a different domain as the application pool User is member of:
- ADDomain - Domain to query (use either "domain.com" or "DC=Domain,DC=COM" format)
- ADUsername - Username for authentication
- ADPassword - Password for authentication
7) Make sure to recycle the app pool for your web service after you’ve made changes to the web.config
8) You should now be able to use the Web Service. Open your browser and go to the following sites to verify they load correctly:
- http://YourWebServer/YourWebserviceFolder/ad.asmx - For Active Directory related functions
- http://YourWebServer/YourWebserviceFolder/mdt.asmx - For MDT related functions
- http://YourWebServer/YourWebserviceFolder/sccm.asmx - for SCCM related functions.
Test a few functions and make sure it returns the data you expect.
There you go, you should now have a functioning web service to use with your deployments!
-Chris
The information provided in this post is “as-is”, use at your own risk and please be sure to test appropriately!
This method has been superseded by a much easier method with MDT 2010 Update 1. Read this post here for the new method.
Mention the SMP to any ConfigMgr OSD guy and he/she will probably give you a dirty look. The most common frustration is when replacing hardware and doing a replace scenario. Most of us have no desire to sit down and create hundreds or thousands of computer associations. We look back to SMS 2003 and think, man that worked slick, why can i just do it like we used to? Well you can without too much trouble actually.
For our environment, we wanted to run USMT in a XP to XP scenario just like we used to. Capture the user data to a network location, then restore from that network location. If we were doing a hardware refresh, then we would run a pre-capture to the network location, then when the new machine is named the same as the old one, the user data would come back down onto that machine from the network share. Hence Kicking It Old School. Modifying a few scripts and some task sequence steps gave us the intended result we wanted.
The components needed for this are:
Modified MDT Toolkit Package, XP Settings Package (cs.ini), and a modified Task Sequence
MDT Toolkit
The first thing we’ll need is a new Toolkit package since we will want to modify a few of the MDT scripts, it’s preferable to just make a new package and then copy in the updated scripts attached to this post, that way you aren’t effecting you toolkit files for all other TS’s in case you wanted to do something different.
I would recommend naming it “MDT 2010 Toolkit Files – USMT3” or something so you know that it’s a modified package for USMT3.
The scripts modified are ztiuserstate.wsf and ztiutility.wsf. ZTIUserState.wsf is modified to force USMT3 to always use the network, and ZTIUtility.wsf has some modifications for connection to UNC’s and creating the necessary folders when they don’t exist. Thanks to Michael Niehaus for the help on that script.
Put the scripts attached to this post in your \scripts folder and either replace the existing ztiuserstate.wsf and ztiutility.wsf or just rename them to “script.old”.
XP Settings Package
Next we’ll need a settings package for the TS. We will want to set the following items in customsettings.ini under the [Default] section. You can modify the Args to what you would like to run.
ScanStateArgs=/v:7 /o /c /uel:30 /targetXP /ui:domain\*
LoadStateArgs=/v:7 /c /uel:30
USMTMigFiles1=MigApp.xml
USMTMigFiles2=MigUser.xml
USMTMigFiles3=MigSys.xml
USMTMigFiles4=custom.xml (if needed)
USMTConfigFile=Config.xml
USMT3=YES
The other items you’ll want to set via the DB or cs.ini is the UDDir and UDShare properties. I do this via the DB so it’s set correctly for all the locations. If you want to do it in your cs.ini via locations, you can do that as well. Just remember to set the values in some way.
UDDir=%OSDComputerName%, and UDShare=\\server\share
Task Sequence
Next we’ll need to modify our TS with the steps we want to run.
First we’ll want to delete or disable some steps in the default TS, your choice.
In the State Capture phase, we want to disable the following steps:
In the State Restore Phase, we want to disable the following steps:
Next we’ll want to add a custom run command line step under State Capture:
Use the following command line, and make sure to select your USMT3 package:
“cscript.exe "%SCRIPTROOT%\ZTIUserState.wsf" /capture”
Next, we’ll add a custom run command line step under State Restore:
Use the following command line, and make sure to select your USMT3 package:
“cscript.exe "%SCRIPTROOT%\ZTIUserState.wsf" /restore”
Next, you’ll to make sure your TS is using your modified Toolkit package and Settings package.
Make sure to change all your appropriate “Use Toolkit Package” steps:
That should be all, be sure to test, hopefully you will find that you can capture/restore data from a network location and that your replace scenarios hopefully are a little easier to work with.
-Chris
Script Files Download Here
I ran into this issue this week and besides reading the logs, this blog post was a good reminder of what you need to do, even for auto-apply drivers. Just a reminder that even when using auto-apply drivers, you still need to have your drivers in a driver package distributed to the DP’s and when you import new drivers, you need to remember to update that package.
Read more here:
http://blogs.technet.com/inside_osd/archive/2008/03/28/when-auto-apply-drivers-fails-to-resolve-content.aspx
The Microsoft® Deployment Toolkit (MDT) 2010 and the Windows® User State Migration Tool (USMT) version 4.0 do not support migration from the Windows 2000 operating system to Windows 7. The scripts that accompany this white paper—named Windows 2000 Migrate User (W2KMigUser)—provide a simple solution for migrating users’ files from Windows 2000 to Windows 7. They are samples that you can use as-is or extend as necessary. Microsoft designed these scripts to work during the State Restore Phase of a MDT 2010 task sequence. W2KMigUser backs up users’ group memberships and files from their Windows 2000 profile folders. In Windows 7, W2KMigUser can restore users’ group memberships, re-create their profile folders, and restore their files. Additionally, the script can capture and re-create any local accounts that have profile folders. Of course, you can control the accounts, groups, profile folders, and files that you want to back up and restore. W2KMigUser can use a network share or removable media as a backup store, but the script does not secure that store.
Read more and download here.