Information Systems:Workstation Imaging With WDS And MDT - Revision history

Norwinu at 22:50, 3 October 2016

2016-10-03T22:50:04Z

Darrenf at 18:09, 29 September 2016

2016-09-29T18:09:24Z

Norwinu at 17:45, 22 August 2016

2016-08-22T17:45:30Z

Norwinu at 17:29, 22 August 2016

2016-08-22T17:29:53Z

Darrenf at 21:47, 10 August 2016

2016-08-10T21:47:00Z

Darrenf at 21:35, 10 August 2016

2016-08-10T21:35:02Z

Darrenf at 21:34, 10 August 2016

2016-08-10T21:34:17Z

Darrenf at 21:32, 10 August 2016

2016-08-10T21:32:04Z

Darrenf at 21:29, 10 August 2016

2016-08-10T21:29:18Z

Darrenf at 21:26, 10 August 2016

2016-08-10T21:26:58Z

@@ Line 42: / Line 42: @@
 [[Category: Desktops/Company Workstations]]
 [[Category: System Administration]]
 [[Category: Imaging]]

← Older revision		Revision as of 18:09, 29 September 2016
Line 42:		Line 42:
	[[Category: Desktops/Company Workstations]]		[[Category: Desktops/Company Workstations]]
	[[Category: System Administration]]		[[Category: System Administration]]
		+	[[Category: Information Systems]]
		+	[[Category: Imaging]]

@@ Line 1: / Line 1: @@
 "Imaging" is when a prebuilt operating system, with or without applications, is transmitted over the network to 1 or more workstations that are either a tower desktop or laptop.
 When new desktops or laptops are purchased they come from the manufacturer with what is called an OEM image installed in a "never booted" state.  The OEM image is created by the manufacturer and has all of the device drivers and manufacturer branded applications built in.  The manufacturer then mass copies the OEM image to thousands of desktops and laptops in a state that when the machine is powered on for the first time, the image is finalized with the "out of box experience".  The OOBE is the wizard that starts when the machine is powered on for the first time and it prompts for basic information such as time/date settings and to acknowledge the EULA.  This OEM image will always use an OEM license of Windows and will always include all the device driver files and manufacturer specific application installers in a folder on the hard drive.  It is absolutely critical that the folder with the drivers and apps is copied or moved off the hardware before work starts on creating a custom image.  The driver and application files need to be saved as they are needed in the process of creating a custom image, which includes a step to delete all existing partitions on said hard drive.
 The reason why the OEM image is not used is because it will never use the volume license of Windows that can be installed multiple times.  The OEM image will also never include all, or even any, of the programs uniPHARM staff need to use on a daily basis.  There is nothing technically wrong with using the OEM license and manually installing our needed programs by hand, it's just very time consuming, inefficient and not a best practice.
 Microsoft provides the software tools to create a custom image for free, except for the actual Windows client license and the Windows server license that is needed to host the image(s).  The 2 main tools are Windows Deployment Services (server role on both 2008 and 2012) and Microsoft Deployment Toolkit.  Known as WDS and MDT, they work in tandem to create and serve images to desktops and laptops.  WDS is the software that contains the unaltered original copies of the Windows DVDs and the boot and capture images that are used during the process of making a custom image.  WDS also stores the final versions of the custom images that are used whenever a workstation needs to be wiped and re-imaged.  The WDS server is listed in the DHCP scope as a PXE boot responder so that when a workstation boots from the network, the WDS server makes the expected response.  MDT is much more focused on the customization and assembly of the image as well as keeping an inventory of device drivers and applications.
@@ Line 23: / Line 25: @@
 WDS contains a special capture boot image that only has 1 function which is to take the Sysprepped hard drive contents and turn it into a .wim file that is then uploaded back into WDS as a deployable customized image with a friendly descriptive label.  Again the capture boot image needs to have the network card and HDD controller card drivers inserted into it in order to work correctly.  The captured .wim file may be as large as 20-30GB depending on what was installed onto the sample workstation.  When the capture is complete the customized image can be deployed to the other workstations that are the same as the sample used to create the image.  If you try to deploy the image to radically different hardware, it may or may not work because the drivers may not be present.  This is the main difference between doing it the quick and dirty way versus using MDT.  MDT is crucial when creating images for lots of different hardware that need the same image because it handles driver collection and insertion more gracefully than WDS.
-Some things to keep in mind when creating images...
+==Special considerations when creating images==
 Programs and applications should always be installed for "all users" and not for the logged in user because the logged in user is going to be deleted by Sysprep.  It's a best practice to put anything that needs to go onto the desktop in the Default Profile desktop folder so that a new user without an existing roaming profile get all the shortcuts and favourites that they need.  It's also best practice to have the AD computer account sitting in an OU that does not have any GPO's linked to it.  When you are creating a customized image, a generic "Administrator1" computer account is created and should be left in any OU that has no linked GPO's.  When the imaged is deployed for production use, that's when the permanent computer account can be moved to an OU where GPO's are applied.  This is all because Sysprep is supposed to remove GPO settings during the generalization process - best not to have any in the registry to begin with until after deployment.
@@ Line 35: / Line 37: @@
 The Sophos SSL VPN client cannot be installed before Sysprep because it is user specific with its user specific certificate so you have to manually install the client after deploying an image.  Same situation with the ADP people@work certificate and its required ActiveX software.  The ASW Analyzer setup is not user specific but gets disconnected between Syspreps so it needs to be done post deployment.
 If this documentation is lacking in any way, there is a small book in DarrenF's office on the shelf called "Deployment Fundamentals - Volume 1".  It has a white cover with a bunch of blue laptops on it.  That book is what was used to setup WDS and MDT in 2012 and can be referenced up until uniPHARM purchases and deploys Windows10.  The versions of WDS and MDT that are being currently used are not compatible with Windows10.

← Older revision		Revision as of 17:29, 22 August 2016
Line 36:		Line 36:

	If this documentation is lacking in any way, there is a small book in DarrenF's office on the shelf called "Deployment Fundamentals - Volume 1". It has a white cover with a bunch of blue laptops on it. That book is what was used to setup WDS and MDT in 2012 and can be referenced up until uniPHARM purchases and deploys Windows10. The versions of WDS and MDT that are being currently used are not compatible with Windows10.		If this documentation is lacking in any way, there is a small book in DarrenF's office on the shelf called "Deployment Fundamentals - Volume 1". It has a white cover with a bunch of blue laptops on it. That book is what was used to setup WDS and MDT in 2012 and can be referenced up until uniPHARM purchases and deploys Windows10. The versions of WDS and MDT that are being currently used are not compatible with Windows10.
		+
−	[[Category: Imaging]]
		+	[[Category: Desktops/Company Workstations]]
		+	[[Category: System Administration]]

@@ Line 25: / Line 25: @@
 Some things to keep in mind when creating images...
-Programs and applications should always be installed for "all users" and not for the logged in user because the logged in user is going to be deleted by Sysprep.  It's a best practice to put anything that needs to go onto the desktop in the Default Profile desktop folder so that a new user without an existing roaming profile get all the shortcuts and favourites that they need.
+Programs and applications should always be installed for "all users" and not for the logged in user because the logged in user is going to be deleted by Sysprep.  It's a best practice to put anything that needs to go onto the desktop in the Default Profile desktop folder so that a new user without an existing roaming profile get all the shortcuts and favourites that they need.  It's also best practice to have the AD computer account sitting in an OU that does not have any GPO's linked to it.  When you are creating a customized image, a generic "Administrator1" computer account is created and should be left in any OU that has no linked GPO's.  When the imaged is deployed for production use, that's when the permanent computer account can be moved to an OU where GPO's are applied.  This is all because Sysprep is supposed to remove GPO settings during the generalization process - best not to have any in the registry to begin with until after deployment.
 MochaSoft is setup to have a configuration file that contains its license info in the appdata\roaming folder of the Default Profile so that no matter who logs into that workstation, MochaSoft starts and connects to Bart without asking for the license code to be typed in.
@@ Line 31: / Line 31: @@
 The data folder for Lotus Notes is not part of the users roaming folder because Lotus Notes is a bitch.  I spent an entire week trying to get this to work seamlessly in 2012 and it just don't fly.
-The uniPHARM logo that is applied to all users is in the ProdData folder on C:.  The exact sub folder is Googleable but the logo graphics file needs to be in the right folder before an image is Sysprepped.  Same goes for the start graphic of the pharmacist for the ASW GUI.  If that .gif file isn't included you get the picture of a snow boarder which is stupid.
+The uniPHARM logo that is applied to all users is in the ProdData folder on C:.  The exact sub folder is Googleable but the logo graphics file needs to be in the right folder before an image is Sysprepped.  Same goes for the start graphic of the pharmacist for the ASW GUI.  If that .gif file isn't included, you get the picture of a snow boarder which is stupid.
-The Sophos SSL VPN client cannot be installed before Sysprep because it is user specific with its user specific certificate so you have to manually install the client after deploying an image.  Same situation with the ADP people@work certificate and its required ActiveX software.
+The Sophos SSL VPN client cannot be installed before Sysprep because it is user specific with its user specific certificate so you have to manually install the client after deploying an image.  Same situation with the ADP people@work certificate and its required ActiveX software.  The ASW Analyzer setup is not user specific but gets disconnected between Syspreps so it needs to be done post deployment.
 If this documentation is lacking in any way, there is a small book in DarrenF's office on the shelf called "Deployment Fundamentals - Volume 1".  It has a white cover with a bunch of blue laptops on it.  That book is what was used to setup WDS and MDT in 2012 and can be referenced up until uniPHARM purchases and deploys Windows10.  The versions of WDS and MDT that are being currently used are not compatible with Windows10.

@@ Line 15: / Line 15: @@
 Again, in theory, MDT builds a "Task Sequence" using the "Lite Touch" boot image to take a Windows DVD image, install it, patch it with WSUS and then install the selected (or all) applications with a silent install followed by a Sysprep and capture step to upload the customized image back into WDS.  In theory this is all automated and mostly hands off, but the effort to get to that point only pays off in large organizations.  The full process with MDT and Task Sequences and Lite Touch is great when an organization has a small number of apps that get updated often OR when an organization needs to make lots of different customized images and has the staff to spend time writing PowerShell scripts to really leverage the abilities of MDT.  For uniPHARM, MDT was needed and properly taken advantage of in 2012, but since we don't make changes to our existing images that often, it's not critical.  If we upgraded from Windows7 to Windows10 then that would certainly justify starting over with MDT and using it as it was intended.
-The quick and dirty way (which was used in the summer of 2016) is to bypass MDT completely.  This was possible because the laptops in 2016 that were to be deployed were all identical.  In 2012, there were 3 different models of laptops and a dozen different models of desktops that all benefitted from doing MDT way.  The quick and dirty method is to first save the drivers and apps from the original OEM image and then to burn factory restore DVDs for that model of laptop using the built in utility.  Second, the network card and hard drive controller drivers need to be imported into WDS.  Above it was stated that device drivers are imported into MDT and that is correct.  Drivers can also be imported into WDS so that they can be inserted into boot images.  Boot images are the pre-installation environments that the workstation needs to boot to, in order to have the OS installed.  The boot images can only be customized by adding in drivers so that new workstation models can actually boot from them.  This is why the network card and HDD controller drivers are so important because without them the OS .wim file can't be downloaded or applied.  Once those drivers are inserted into the correct 32bit or 64bit boot image, the new workstation can boot from it and install the corresponding 32bit or 64bit OS.
+The quick and dirty way (which was used in the summer of 2016) is to bypass MDT completely.  This was possible because the laptops in 2016 that were to be deployed were all identical.  In 2012, there were 3 different models of laptops and a dozen different models of desktops that all benefitted from doing it the MDT way.  The quick and dirty method is to first save the drivers and apps from the original OEM image and then to burn factory restore DVDs for that model of laptop using the built in utility.  Second, the network card and hard drive controller drivers need to be imported into WDS.  Above it was stated that device drivers are imported into MDT and that is correct.  Drivers can also be imported into WDS so that they can be inserted into boot images.  Boot images are the pre-installation environments that the workstation needs to boot to, in order to have the OS installed.  The boot images can only be customized by adding in drivers so that new workstation models can actually boot from them.  This is why the network card and HDD controller drivers are so important because without them the OS .wim file can't be downloaded or applied.  Once those drivers are inserted into the correct 32bit or 64bit boot image, the new workstation can boot from it and install the corresponding 32bit or 64bit OS.
 When the OS is finished installing, you are presented with a workstation that only has Windows installed, there are no other apps or customizations included.  At this point the next step is to use the manufacturer's utility to download and install any remaining device drivers and any important manufacturer apps that control power or wireless features for example.  Once all the drivers and hardware is set, the next step is to patch the OS up to the latest level.  In the case of Windows7, there is a new rollup that isn't called Service Pack 2 but it really is - and contains all 400ish updates that have been published since Service Pack 1 which does need to be installed first unless its included in the base OS DVD image.

@@ Line 13: / Line 13: @@
 MDT can also catalog applications in the same way that it does for device drivers.  The idea is that all of the installer files for all of the needed programs are imported into MDT so that they can be installed programmatically during the customization process, just like the device drivers.  In theory this does work but in the real world not all program installers are available as .msi files.  MDT works best with .msi files that can take a silent install parameter.  Installers that are .exe files or some sort of Java garbage don't really work gracefully with MDT.  For example, Microsoft Office can be a customized silent install with MDT while the ASW GUI cannot because it is an exe and as old as Noah.  Complex programs like Lotus Notes may wrap an .msi inside of an .exe and you have to decide if it's worth the effort to untie that knot.
-Again, in theory, MDT builds a "Task Sequence" using the "Lite Touch" boot image to take a Windows DVD image, install it, patch it with WSUS and then install the selected (or all) applications with a silent install followed by a Sysprep and capture step to upload the customized image back into WDS.  The full process with MDT and Task Sequences and Lite Touch is great when an organization has a small number of apps that get updated often OR when an organization needs to make lots of different customized images and has the staff to spend time writing PowerShell scripts to really leverage the abilities of MDT.  For uniPHARM, MDT was needed and properly taken advantage of in 2012, but since we don't make changes to our existing images that often, it's not critical.  If we upgraded from Windows7 to Windows10 then that would certainly justify starting over with MDT and using it as it was intended.
+Again, in theory, MDT builds a "Task Sequence" using the "Lite Touch" boot image to take a Windows DVD image, install it, patch it with WSUS and then install the selected (or all) applications with a silent install followed by a Sysprep and capture step to upload the customized image back into WDS.  In theory this is all automated and mostly hands off, but the effort to get to that point only pays off in large organizations.  The full process with MDT and Task Sequences and Lite Touch is great when an organization has a small number of apps that get updated often OR when an organization needs to make lots of different customized images and has the staff to spend time writing PowerShell scripts to really leverage the abilities of MDT.  For uniPHARM, MDT was needed and properly taken advantage of in 2012, but since we don't make changes to our existing images that often, it's not critical.  If we upgraded from Windows7 to Windows10 then that would certainly justify starting over with MDT and using it as it was intended.
 The quick and dirty way (which was used in the summer of 2016) is to bypass MDT completely.  This was possible because the laptops in 2016 that were to be deployed were all identical.  In 2012, there were 3 different models of laptops and a dozen different models of desktops that all benefitted from doing MDT way.  The quick and dirty method is to first save the drivers and apps from the original OEM image and then to burn factory restore DVDs for that model of laptop using the built in utility.  Second, the network card and hard drive controller drivers need to be imported into WDS.  Above it was stated that device drivers are imported into MDT and that is correct.  Drivers can also be imported into WDS so that they can be inserted into boot images.  Boot images are the pre-installation environments that the workstation needs to boot to, in order to have the OS installed.  The boot images can only be customized by adding in drivers so that new workstation models can actually boot from them.  This is why the network card and HDD controller drivers are so important because without them the OS .wim file can't be downloaded or applied.  Once those drivers are inserted into the correct 32bit or 64bit boot image, the new workstation can boot from it and install the corresponding 32bit or 64bit OS.

@@ Line 11: / Line 11: @@
 MDT is where device drivers and applications are combined into a base Windows DVD image so that the customized image can be captured and saved into WDS.  The first step is to import all the saved device drivers that were copied off the OEM image.  MDT can scan a large folder full of drivers and put them into the MDT database.  The list of drivers for all the hardware is then viewable with version numbers in MDT.  When you are making an image for lots of different models of desktops and laptops, it is very important to make sure that all the drivers that are needed are available in MDT.  Collecting drivers for lots of different models can be very time consuming unless they are copied off from the OEM image.  At the absolute minimum, the most critical drivers are network card and hard drive controller drivers.  Without BOTH, the image cannot be applied to the hardware.  Obviously having drivers for all the different components is better than just having the minimum.
-MDT can also catalog applications in the same way that it does for device drivers.  The idea is that all of the installer files for all of the needed programs are imported into MDT so that they can be installed programmatically during the customization process, just like the device drivers.  In theory this does work but in the real world not all program installers are available as .msi files.  MDT works best with .msi files that can take a silent install parameter.  Installers that are .exe files or some sort of Java garbage don't really work gracefully with MDT.  For example, Microsoft Office can be a customized silent install with MDT while the ASW GUI cannot because it is an exe and old as Noah.  Complex programs like Lotus Notes may wrap an .msi inside of an .exe and you have to decide if it's worth the effort to untie that knot.
+MDT can also catalog applications in the same way that it does for device drivers.  The idea is that all of the installer files for all of the needed programs are imported into MDT so that they can be installed programmatically during the customization process, just like the device drivers.  In theory this does work but in the real world not all program installers are available as .msi files.  MDT works best with .msi files that can take a silent install parameter.  Installers that are .exe files or some sort of Java garbage don't really work gracefully with MDT.  For example, Microsoft Office can be a customized silent install with MDT while the ASW GUI cannot because it is an exe and as old as Noah.  Complex programs like Lotus Notes may wrap an .msi inside of an .exe and you have to decide if it's worth the effort to untie that knot.
 Again, in theory, MDT builds a "Task Sequence" using the "Lite Touch" boot image to take a Windows DVD image, install it, patch it with WSUS and then install the selected (or all) applications with a silent install followed by a Sysprep and capture step to upload the customized image back into WDS.  The full process with MDT and Task Sequences and Lite Touch is great when an organization has a small number of apps that get updated often OR when an organization needs to make lots of different customized images and has the staff to spend time writing PowerShell scripts to really leverage the abilities of MDT.  For uniPHARM, MDT was needed and properly taken advantage of in 2012, but since we don't make changes to our existing images that often, it's not critical.  If we upgraded from Windows7 to Windows10 then that would certainly justify starting over with MDT and using it as it was intended.