Today I received the following message:
Congratulations! We’re pleased to inform you that your contributions to Microsoft online technical communities have been recognized with the Microsoft Community Contributor Award.
The Microsoft Community Contributor Award is reserved for participants who have made notable contributions in Microsoft online community forums such as TechNet, MSDN and Answers. The value of these resources is greatly enhanced by participants like you, who voluntarily contribute your time and energy to improve the online community experience for others.
For more information about my contributions to Microsoft online technical communities check this site: http://social.technet.microsoft.com/profile/henk%20hoogendoorn/?type=forum
Thanks Microsoft!
Tuesday, June 28, 2011
Microsoft Deployment Toolkit (MDT) 2010 explained
Last week I used an existing Microsoft Deployment Toolkit (MDT) 2010 installation on a Windows Server 2008 server. This for creating a new Windows 7 SP1 image and deploying it also. Most of times I install MDT for ConfigMgr integration only. Now for me the change to see MDT features and functionality. In this blog we have a look at the setup and choices made during configuration.
There was already an MDT installation present; this because of Windows XP deployment. Therefore I decided to create a new Deployment Share first. A Deployment Share is the place where packages, drivers and applications will be placed. This is a real share on the disk, so Deployment Share is a good chosen word here.
In MDT 2008 it was necessary to create an additional Deployment Point also. In MDT 2010 this is not needed anymore. All components are placed on a single Deployment Share now. There can be multiple Deployment Shares if you want. This for using different INI-files needed (for example). Multiple Deployment Shares can be opened at the same time in the MDT console. These can be linked, so that when content is changed, it will be updated on the other share(s) also.
After that importing an Operating System image is needed. This can be done with a "Full set of source files" from installation media. The best thing to do is to start a "Standard Client task sequence" to create a new OS image. Just make sure that an image capture is configured in the task sequence used for creating a OS image.
The OS image created can be imported again later to make it available in other task sequences. Select then the "Custom image file" in the "Standard Client task sequence". This task sequence (used for deployment) can be included applications, drivers and motifications also.
Best practice for the task sequence used for capturing, is not including an administator password and product key in it. Also the device used for capturing must be a workgroup member. The administator password and product key can be configured later during deployment.
Now have a look at the Deployment Share properties. These include the Bootstrap.ini and Rules (customsettings.ini) files. These settings will determine the behaviour during Operating System Deployment. After that an update is needed on the Deployment Share, which will also create the necessary ISO and WIM files (again) needed for Boot functionality.
Make sure to update the Boot image files on Windows Deployment Services (WDS) when new settings are placed in the Bootstrap.ini file. Otherwise it will not be functional when starting a new image deployment.
Note: When using "_SMSTSORGNAME=" the IT Organization name can be changed during task sequence progress.
The ISO file can be used to burn on CD/DVD or USB device for booting from media. The WIM file can be used in Windows Deployment Services (WDS) for booting with PXE boot. Just press F12 during startup en see the magic happen. After choosing the right Boot image, the OS deployment can start without any other messages displayed. In this environment only the computername is needed. That's all needed!
It's nice to see that MDT 2010 is easy to setup and not that hard to use for OS deployment. Just configure the necessary steps needed, and OS deployment will be available. MDT 2010 is (without the usage of ConfigMgr) still a very good deployment solution!
The most common error during re-deployment was the following one:
Property LTISuspend is now = Litetouch has encountered an Environment Error (Boot into WinPE!).
If booting from a USB Flash Disk, please remove all drives before Retrying.
Otherwise, ensure the hard disk is selected first in the boot order of the BIOS.
This because after deployment there may be still C:\MININT or C:\_SMSTaskSequence folders left. When OS deployment is done these folders are not necessary anymore and can be deleted.
The best way for doing this is start from Windows PE and open a command shell. Type in the following commands then: (1) Diskpart (2) Select Disk 0 (3) clean. After that start over again in Windows PE and OS deployment will be functional then.
One last solution is using Johan Arwidmark's Final Configuration script. This script will clean out any Leftover MININT or Sysprep folders. Enable WindowsUpdate, Set a default domain value (read from the JOINDOMAIN environment variable), and then do a proper final reboot. It can be found here: http://www.deployvista.com/Blog/tabid/70/EntryID/61/language/en-US/Default.aspx
Note: You need to set SkipFinalSummary=YES in customsettings.ini (the script will check for it)
Thanks to Anton van Pelt, Twitter: @antonaustirol25 for sharing his knowledge on this!
There was already an MDT installation present; this because of Windows XP deployment. Therefore I decided to create a new Deployment Share first. A Deployment Share is the place where packages, drivers and applications will be placed. This is a real share on the disk, so Deployment Share is a good chosen word here.
In MDT 2008 it was necessary to create an additional Deployment Point also. In MDT 2010 this is not needed anymore. All components are placed on a single Deployment Share now. There can be multiple Deployment Shares if you want. This for using different INI-files needed (for example). Multiple Deployment Shares can be opened at the same time in the MDT console. These can be linked, so that when content is changed, it will be updated on the other share(s) also.
After that importing an Operating System image is needed. This can be done with a "Full set of source files" from installation media. The best thing to do is to start a "Standard Client task sequence" to create a new OS image. Just make sure that an image capture is configured in the task sequence used for creating a OS image.
The OS image created can be imported again later to make it available in other task sequences. Select then the "Custom image file" in the "Standard Client task sequence". This task sequence (used for deployment) can be included applications, drivers and motifications also.
Best practice for the task sequence used for capturing, is not including an administator password and product key in it. Also the device used for capturing must be a workgroup member. The administator password and product key can be configured later during deployment.
Now have a look at the Deployment Share properties. These include the Bootstrap.ini and Rules (customsettings.ini) files. These settings will determine the behaviour during Operating System Deployment. After that an update is needed on the Deployment Share, which will also create the necessary ISO and WIM files (again) needed for Boot functionality.
Make sure to update the Boot image files on Windows Deployment Services (WDS) when new settings are placed in the Bootstrap.ini file. Otherwise it will not be functional when starting a new image deployment.
Note: When using "_SMSTSORGNAME=" the IT Organization name can be changed during task sequence progress.
The ISO file can be used to burn on CD/DVD or USB device for booting from media. The WIM file can be used in Windows Deployment Services (WDS) for booting with PXE boot. Just press F12 during startup en see the magic happen. After choosing the right Boot image, the OS deployment can start without any other messages displayed. In this environment only the computername is needed. That's all needed!
It's nice to see that MDT 2010 is easy to setup and not that hard to use for OS deployment. Just configure the necessary steps needed, and OS deployment will be available. MDT 2010 is (without the usage of ConfigMgr) still a very good deployment solution!
The most common error during re-deployment was the following one:
Property LTISuspend is now = Litetouch has encountered an Environment Error (Boot into WinPE!).
If booting from a USB Flash Disk, please remove all drives before Retrying.
Otherwise, ensure the hard disk is selected first in the boot order of the BIOS.
This because after deployment there may be still C:\MININT or C:\_SMSTaskSequence folders left. When OS deployment is done these folders are not necessary anymore and can be deleted.
The best way for doing this is start from Windows PE and open a command shell. Type in the following commands then: (1) Diskpart (2) Select Disk 0 (3) clean. After that start over again in Windows PE and OS deployment will be functional then.
One last solution is using Johan Arwidmark's Final Configuration script. This script will clean out any Leftover MININT or Sysprep folders. Enable WindowsUpdate, Set a default domain value (read from the JOINDOMAIN environment variable), and then do a proper final reboot. It can be found here: http://www.deployvista.com/Blog/tabid/70/EntryID/61/language/en-US/Default.aspx
Note: You need to set SkipFinalSummary=YES in customsettings.ini (the script will check for it)
Thanks to Anton van Pelt, Twitter: @antonaustirol25 for sharing his knowledge on this!
Labels:
Images,
MDT,
MDT 2010,
Microsoft Deployment Toolkit,
OSD
Thursday, June 16, 2011
Windows Deployment Services on Server 2008 R2
Yesterday I installed Windows Deployment Services (WDS) on a Windows Server 2008 R2 server. A good possibility to see the new features available in this release. Most of times I install WDS needed for ConfigMgr installations. Then there's no need to configure WDS; this will be left unconfigured then. In this blog we have a look at the new features in this release.
First install the WDS role on a Windows Server 2008 R2 server. By default both Deployment Server and Transport Server will be installed. After that configuration must be done. Just import Boot Images, and create Capture Images from that. Then there's the possibility to add images for all kind of Windows editions. In this release there's no support available for RIS (Remote Installation Services) anymore. This was formerly known as "Legacy Images" in Windows Server 2003 editions.
Let's have a look at the console now. There will be default folders for Install Images, Boot Images, Pending Devices, Multicast Transmissions and Drivers in it. Drivers has default folders for All Packages and DriverGroup1 in it. What's the meaning of this folders?:
As mentioned before there are new features in this release. These are Multicast support and additional Driver packages for deployment. That way there's no need to create multiple OS Images for all kind off type devices. Just create multiple Driver packages and add them to the default image; with the use off a query. Let's have a look at all the new functionality.
Multicast: Transmission Name: This wizard creates a multicast transmission for an image. Once created, Windows Deployment Services will transmit the image to multiple clients using a single transmission, instead of one transmission for eacht client. This can significantly reduce the amount of network bandwidth that is used.
Rightclick on Drivers will show these options.
"Add Driver Package" will let you choose between driver packages from an .inf file or a specific folder with drivers. Once the packages are on your server, you can define which client computers will install them using driver groups and you can add them to boot images.
"Add Driver Group" will create a new driver group which can be used to create a collection of driver packages. This wizard helps you define these clients based on the client's hardware and the install image that is selected during setup.
There are also more possibilities with "Enable/Disable Driver Packages" and "Delete Driver Packages".
Rightclick on DriverGroup1 will show these options.
Choose Properties to create new filters. You can use filters to define which clients install the driver packages in this group, based upon the hardware of the installing client and the install image that the client chooses.
When adding a new filter there is the choice between: Manufacturer, Bios Vendor, Bios Version, Chassis Type, UUID, OS Version, OS Edition and OS Language.
There are also more possibilities with "Modify Filters for this Group" and "Add Driver Packages to this Group".
With WDS on Server 2008 R2 there's better support for multiple devices now! No need to create multiple OS Images anymore; just create multiple driver packages for that. With Multicast support bandwidth can be saved, when multiple devices must be re-installed during working hours. It's good to see that WDS without the need of MDT and/or ConfigMgr is a goodworking solution for deployment.
First install the WDS role on a Windows Server 2008 R2 server. By default both Deployment Server and Transport Server will be installed. After that configuration must be done. Just import Boot Images, and create Capture Images from that. Then there's the possibility to add images for all kind of Windows editions. In this release there's no support available for RIS (Remote Installation Services) anymore. This was formerly known as "Legacy Images" in Windows Server 2003 editions.
Let's have a look at the console now. There will be default folders for Install Images, Boot Images, Pending Devices, Multicast Transmissions and Drivers in it. Drivers has default folders for All Packages and DriverGroup1 in it. What's the meaning of this folders?:
- Install Images: All Images used for Windows deployment, with the possibility to create folders for overview;
- Boot Images: Specific Images used for deploying and capturing new OS Images;
- Pending Devices: Once this setting is enabled, you can approve and reject computers in the pane;
- Multicast Transmissions: Once created, Windows Deployment Services will transmit the image to multiple clients using a single transmission, instead of one transmission for each client;
- Drivers: New folder for creating driver packages and driver groups;
- All Packages: You can use Windows Deployment Services to add driver packages to the server and configure them to be deployed to client computers along with the install image;
- DriverGroup1: You can use filters to map client computers to the packages in a driver group. The filters define which clients will install the drivers.
As mentioned before there are new features in this release. These are Multicast support and additional Driver packages for deployment. That way there's no need to create multiple OS Images for all kind off type devices. Just create multiple Driver packages and add them to the default image; with the use off a query. Let's have a look at all the new functionality.
Multicast: Transmission Name: This wizard creates a multicast transmission for an image. Once created, Windows Deployment Services will transmit the image to multiple clients using a single transmission, instead of one transmission for eacht client. This can significantly reduce the amount of network bandwidth that is used.
Rightclick on Drivers will show these options.
"Add Driver Package" will let you choose between driver packages from an .inf file or a specific folder with drivers. Once the packages are on your server, you can define which client computers will install them using driver groups and you can add them to boot images.
"Add Driver Group" will create a new driver group which can be used to create a collection of driver packages. This wizard helps you define these clients based on the client's hardware and the install image that is selected during setup.
There are also more possibilities with "Enable/Disable Driver Packages" and "Delete Driver Packages".
Rightclick on DriverGroup1 will show these options.
Choose Properties to create new filters. You can use filters to define which clients install the driver packages in this group, based upon the hardware of the installing client and the install image that the client chooses.
When adding a new filter there is the choice between: Manufacturer, Bios Vendor, Bios Version, Chassis Type, UUID, OS Version, OS Edition and OS Language.
There are also more possibilities with "Modify Filters for this Group" and "Add Driver Packages to this Group".
With WDS on Server 2008 R2 there's better support for multiple devices now! No need to create multiple OS Images anymore; just create multiple driver packages for that. With Multicast support bandwidth can be saved, when multiple devices must be re-installed during working hours. It's good to see that WDS without the need of MDT and/or ConfigMgr is a goodworking solution for deployment.
Tuesday, June 7, 2011
ConfigMgr 2012 Beta 2 with App-V integration
In ConfigMgr 2007 with R2 it was possible to import App-V packages and stream them to the end user. There was also the possibility to choose between streaming or local delivery for that. Have a look at this blog for more information about ConfigMgr 2007 with App-V integration: http://henkhoogendoorn.blogspot.com/2010/12/configmgr-2007-with-app-v-integration.html
Because of multiple reasons there was the choice between App-V integration in ConfigMgr 2007 or using the stand-alone App-V solution. I have selected a few websites with more information about that:
Personally I think that the combination of ConfigMgr 2007 and App-V is quite good, only it's better to keep them seperate. This because it's a bit slower in ConfigMgr and there's no publishing functionality in it. That way you must decide where to put the shortcuts in the App-V package, during sequencing. Also all shortcuts will be displayed on the desktop or in the start menu after publishing; no changes on that possible.
The advantage of putting App-V packages in ConfigMgr 2007, and using a Distribution Point (DP) for streaming is integration. No need for having App-V Management and/or Streaming servers that way. Just configure the (existing) ConfigMgr server and deploy all your applications from one platform! The only App-V installation needed is the Sequencer for creating App-V packages. Instead of multiple App-V servers, more Distribution Points are recommended then.
Now have a look at the combination of ConfigMgr 2012 Beta 2 and App-V. In ConfigMgr 2012 things are quite different. Open the ConfigMgr console, Select Application Management, rightclick on that and choose Create Application. There are four (4) choices now, with Microsoft Application Virtualization in here also. Just import a already sequenced application here.
When looking in the Applications screen there are no orange App-V icons anymore. On every application there are tabs for Deployment Types and Deployment (first known as advertisement). On deployment types there are new Content settings seen:
For streaming App-V packages from Distribution Points no further configuration is needed in ConfigMgr 2012. Distribution Points have streaming functionality by default now. For App-V integration on the desktops an App-V 4.6 SP1 client is needed. No further configuration is needed on that also. Sometimes the Cache will be placed on another drive, and the Cache size will be enlarged. The file type extensions will be automatically associated to the new applications.
That's all you need to have for App-V integration in ConfigMgr 2012. Because off better user support in ConfigMgr 2012, App-V integration will be a more interesting choice now!
Because of multiple reasons there was the choice between App-V integration in ConfigMgr 2007 or using the stand-alone App-V solution. I have selected a few websites with more information about that:
- App-V 4.6 and ConfigMgr 2007 SP2: even better together
- How to integrate App-V with SCCM without losing the features you care about
- Integration App-V and SCCM
- SCCM / App-V hybrid architecture
- App-V - Introduction, Components and SCCM Integration
- SCCM and App-V Integration Whitepaper
Personally I think that the combination of ConfigMgr 2007 and App-V is quite good, only it's better to keep them seperate. This because it's a bit slower in ConfigMgr and there's no publishing functionality in it. That way you must decide where to put the shortcuts in the App-V package, during sequencing. Also all shortcuts will be displayed on the desktop or in the start menu after publishing; no changes on that possible.
The advantage of putting App-V packages in ConfigMgr 2007, and using a Distribution Point (DP) for streaming is integration. No need for having App-V Management and/or Streaming servers that way. Just configure the (existing) ConfigMgr server and deploy all your applications from one platform! The only App-V installation needed is the Sequencer for creating App-V packages. Instead of multiple App-V servers, more Distribution Points are recommended then.
Now have a look at the combination of ConfigMgr 2012 Beta 2 and App-V. In ConfigMgr 2012 things are quite different. Open the ConfigMgr console, Select Application Management, rightclick on that and choose Create Application. There are four (4) choices now, with Microsoft Application Virtualization in here also. Just import a already sequenced application here.
When looking in the Applications screen there are no orange App-V icons anymore. On every application there are tabs for Deployment Types and Deployment (first known as advertisement). On deployment types there are new Content settings seen:
- Persist content in the client cache
- Enable peer-to-peer content distribution
- Load content into AppV cache before launch
- Fast > Download content (changed to Stream content in my environment)
- Slow/unreliable > Do not download (changed to Download content in my environment)
For streaming App-V packages from Distribution Points no further configuration is needed in ConfigMgr 2012. Distribution Points have streaming functionality by default now. For App-V integration on the desktops an App-V 4.6 SP1 client is needed. No further configuration is needed on that also. Sometimes the Cache will be placed on another drive, and the Cache size will be enlarged. The file type extensions will be automatically associated to the new applications.
New applications available from ConfigMgr 2012
File type extensions are automatically associated
That's all you need to have for App-V integration in ConfigMgr 2012. Because off better user support in ConfigMgr 2012, App-V integration will be a more interesting choice now!
Subscribe to:
Posts (Atom)