While searching for an error I received while running sysprep on my Windows 7 x64 reference machine, I came accross this interesting page from Microsoft.
Seems like my error (the issue due to Windows Media Player sharing being enabled) and many other known issues are discussed in this article.
http://technet.microsoft.com/en-us/library/dd349350(WS.10).aspx
hope it helps you out…
In previous parts of this guide we’ve setup MDT 2010 and have it configured. Now it’s time to add WSUS integration to automatically install the latest patches while deploying Windows 7.
First download and install WSUS 3.0 x64 version or WSUS 3.0 x86 version (for Server 2003), or add the WSUS server role of you’re on Server 2008:
The WSUS installation window is underneath the Server Roles window, use alt-tab or the taskbar to proceed with the installation.
Configure WSUS to your needs:
Update each Task Sequence you want updates installed through WSUS. By default ‘Disable this step’ is checked, to enable WSUS for this TS just remove the check:
Add WSUSServer to your CustomSettings.ini:
WSUSServer=http://wsusServerName
or
WSUSServer=http://wsusServerName:portnumber
Depending on your WSUS configuration.
Configuration is done, time to deploy a Win 7 client.
After the image is applied, Windows Update is doing its job using our WSUS server:
Just to make sure, take a look at the Installed Updates on the newly deployed client:
WSUS integration succeeded!
Please find other parts here:
Windows 7 Lite Touch installation with MDT 2010 – Part 1
Windows 7 Lite Touch installation with MDT 2010 – Part 2
Windows 7 Lite Touch installation with MDT 2010 – Part 3
Meanwhile MDT 2010 has reached Update 1, time to catch up where we left in part 2.
We will configure WDS to use PXE boot, use SQL Server to retrieve the computer name and have some beer afterwards.
First configure a DHCP scope to serve the clients with an IP address. Then install the Windows Deployment Service (WDS) role on your MDT box, and configure WDS. I like to have a PXE delay of 3 seconds and I’m running DHCP on the same server as WDS. So I need to check ‘Do not listen on port 67’ and ‘Configure DHCP option 60 to indicate that this server is also a PXE server’.
Now we have to import the WinPE boot images, previous generated by MDT, into WDS:
Browse to the Boot-folder in the Deployment Share, and select the LiteTouch-wim-file(s) (I’m importing the x64 version only, as I don’t use Windows 7 x86 for now):
Boot your client machine and hit F12 to boot into PXE, or choose boot from network card in the BIOS.
We still have to choose a computer name during deployment:
Using MS SQL Server (Express) you can fully automate this!
In my test lab I will use SQL Express 2008 SP1. Open SQL Server Configuration manager, set SQL Server Browser to automatic and start the service:
Enable Named Pipes in SQL Server Configuration Manager:
Restart the SQL Server service:
Start SQL Management Studio and create a Security Login (I’ll use my MDT domain-join-user):
Add the db_datareader and db_datawriter permissions for the domain\svc-join user to the MDT database:
Open the Deployment Workbench and Create a new database:
We have finished creating the MDT database.
Now we have to configure CustomSettings.ini before we can use the database:
By clicking Configure Database Rules, you actually adding extra lines to CustomSettings.ini in order to make a connection to the database. Select what you need:
Take a look at your CustomSettings.ini file (by right-clicking the DeploymentShare > Properties > Rules tab):
You can modify CustomSettings.ini further. To join a domain for example:
SkipDomainMembership=YES
JoinDomain=thedspot.local
DomainAdmin=svc-join
DomainAdminDomain=thedspot.local
DomainAdminPassword=*
MachineObjectOU=OU=Computers,OU=Unmanaged,DC=thedspot,DC=local
Hit Computers > New to add a MAC address and corresponding computername (OSDComputerName):
Our LiteTouch deployment succeeded:
The computer name was retrieved from the database and domain join was successful.
Please find other parts here:
Windows 7 Lite Touch installation with MDT 2010 – Part 1
Windows 7 Lite Touch installation with MDT 2010 – Part 2
Windows 7 Lite Touch installation with MDT 2010 – Part 4
Microsoft released an update for the company’s free operating system deloyment solution. If you’re planning to migrate to Windows 7, Server 2008 R2 or Office 2010, MDT is the tool you need. Here at the D Spot we have blogged a lot about MDT already. Keep yourself up to date and read our MDT related posts.
A smooth and simple upgrade process. Installing MDT 2010 Update 1 will preserve your existing MDT configuration, with simple wizards to upgrade existing deployment shares and Configuration Manager installations.
Download binaries and documentation at Microsoft.
This kit will help you complete a Proof of Concept (PoC) at your organization, at a customer or get familar with some Microsoft products in a lab environment.
Allowing you to quickly evaluate the new Microsoft desktop technologies, including Windows 7, Office 2010, Internet Explorer 8, and Application Virtualization (AppV) with Microsoft Desktop Optimization Pack technology.
It will also familiarize you with some of the important deployment tools provided by Microsoft to assist with your broader deployment efforts. This PoC isn’t meant to be comprehensive training mechanism but rather an introductory set of modules to familiarize you with tools and technologies.
Included in the package:
In short, a package that any consultant arriving on a mission around Windows 7 should have.
Recently I had a problem with my Windows 7 clients (built with my new and freshly created image) where they would not get activated by the KMS server. After some research I noticed that the KMS counter was not updated with new client and so my KMS server would never reach the point where it would actually start activating my clients (25 clients).
The reason for the KMS server not updating it’s counter was the fact that all my clients where reporting to the KMS server with the same Client Machine ID (CMID) which I noticed trough the events it reported in the Key Management Service event log of my KMS server.
If you ‘Bing’ on this one you will get lot’s of posts where this is due to the sysprep command which is not ran with the /generalize parameter. This parameter removes all hardware dependencies and when building a new client, it will create a new CMID.
However I did use the /generalize parameter so why do I get the same behavior. The solution is simple but it did take me some time to notice that I seemed to have missed the <skiprearm> setting in my xml answer file. This setting should be removed before using the image in a production environment! If not you’ll end up rebuilding your image like me…
More info: http://support.microsoft.com/kb/929829
Grtz,
Steve.
As my first contribution to the D-Spot I would like to give some more detailed information about a specific Microsoft Tool: ACT 5.5. This tool is mainly used to retrieve information from one or more computers. More info about the ACT can be found here.
The Microsoft Application Compatibility Toolkit (ACT) version 5.5 contains the necessary tools and documentation to evaluate and mitigate application compatibility issues before deploying Windows 7, Windows Vista®, a Windows Update, or a new version of Windows® Internet Explorer® in your environment.
Before installing the ACT you need to have an SQL server installed. These are the SQL server versions you can use:
The client OS you can install the ACT on are all the client OS between Windows XP SP2 and Windows 7. The server OS needs to be at least Windows Server 2003 SP2.
When launching the installer of the ACT (Application Compatibility Toolkit.msi) a wizard starts and you need to go through the 6 steps. The wizard will ask you some questions about the SQL server database, log files, etc.
This is the main tool you use to manage the DCP’s (Data Collector Package) and all the retriever information from all the machines you ran the ACT on. The ACT is dependent from an agent (called a DCP) which you create in the ACM. In the following screenshots you can see how to create such a Data Collector Package.
Once you saved the msi-file you can start to distribute the package among all the computers you want the ACT to retrieve the information from. There are several ways to do this:
If the file has been run on a computer you’ll receive the information in the ACM. In the following set of screenshots the DCP will be run on a local machine and outputting the data to the same machine.
When the output is available in the ACM we can analyze all the information:
Be aware:
The “ACT Log Processing Service” needs to be started otherwise there will be no output shown in the ACM.
Last Wednesday we hosted our seminar “Managing the dynamic desktop? Windows 7 deployment”. This seminar not only listed many of the new features and functionality that are included in Windows 7 but also answered many deployment questions. Some of them were “how do I know which deployment system is best-suited for my organization?” and “how can I certify this to be my final mass deployment”.
The result can be found here:
http://seminar.the-d-spot.org/Windows 7 Presentation_part1.pdf
http://seminar.the-d-spot.org/Windows 7 Presentation_part2.pdf
Op 4 februari kan je een Microsoft TechNet Live Meeting volgen over het automatiseren van Windows 7 en Windows 2008 R2 installaties.
Tijdens deze livemeeting zullen we u tonen hoe u aan de hand van onze bestaande tools zoals “Microsoft Deployment toolkit” en de “Windows Deployment Services” heel snel Windows 7 en Windows Server 2008 R2 kan installeren. Verder gaan we dieper in op de “boot from VHD” functionaliteit.
U zal ook merken dat we in Windows 7 en Windows Server 2008 R2 nieuwe mogelijkheden hebben om de installatie te vergemakkelijken en automatiseren.
Taal/talen: Nederlands.
Product(en): Windows 7,Windows Server 2008 R2.
Doelgroep(en): Infrastructuurspecialisten,IT-besluitvormer,IT-generalist,IT-implementeerder,IT-manager,Specialist voor desktop/eindgebruikers,Technisch persoon met invloed op BDM.
Duur: 120 Minuten
Begindatum: donderdag 4 februari 2010 14:00
Microsoft Deployment Toolkit 2010 has some nice improvements to its successors in the driver handling department. I will describe how I like to manage drivers in MDT 2010.
First we have to build the ‘Out-of-Box Drivers’ folder structure and import drivers. I have subdirectories for each architecture, brand and model. This is what my folder tree looks like:
However, you can build your own structure, as long as you respect the proper model & brand (make) name of the vendors.
To build up the folder structure you have to know the model name of your hardware. To retrieve the proper computer name execute at command prompt: ‘wmic csproduct get name’, to get the exact name WMI queries to determine the computer model. In my case the computer name is “Latitude E5500”. My colleague for example, uses a HP laptop “HP Compaq 6730b (GW687AV)”. Use this info to build up folders in MDT’s Out-of-Box Drivers (you can make your own structure, as long as the computer and Model names are correct).
Now that we have drivers imported in our Deployment Share, it’s time to move on.
MDT has two different methods to manage drivers (actually three, but we skip DriverPaths used in BDD 2007, as support will probably be removed in future versions).
DriverGroups existed in MDT 2008 already, although the MDT Team added subdirectory support in MDT 2010.
At deployment phase MDT uses WMI to query the proper computer model and only the current model drivers will be injected. In order to get this working properly, you have to use the EXACT model name in your Out-of-Box Driver tree. You don’t want to query dead horses.
Add a new step in your Task Sequence to inject the correct drivers. MDT will query the computer name and inject the drivers which corresponds with the computer name from the Out-of-Box folder structure, right before applying the image at deployment.
I use ‘DriverGroup001’ as Task Sequence Variable, and Win7x64\%Make%\%Model% as value for my Windows 7 x64 TS . You have to adapt this to your Out-of-Box tree. (Don’t use an underscore in your TS variable variable name as I intentional did. thanks Tom!)
As my Task Sequence handles everything, there isn’t anything needed here.
If you don’t like to use a new Task in your TS, you can add DriverGroup variables in customsettings.ini like this:
DriverGroup001=%Make%\%Model%
DriverGroup002=Printers
New in MDT 2010 are DriverSelectionProfiles. These are easy for new MDT admins, very straight forward and easy to use.
Overview:
First you have to create a Profile (or use one of the default profiles):
You can even select Packages and Applications, use it for “bad drivers” aka driver setup packs.
Select what drivers you want to add to the profile;
After making the profiles you can use them in your Task Sequences. The default ‘Inject Drivers’ settings are on the left, the customized one on the right:
You can add Selection Profiles for printer drivers/packages or whatever you want. Just add an extra step in your task sequence like above.
As with DriverGroups you can choose to handle the DriverSelectionProfile in customsettings.ini or in your TS.
Example:
DriverSelectionProfile=Dell Latitude D520 x64
Please do comment if you have any suggestions.