Jump to content


WinOutreach4

Established Members
  • Posts

    47
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by WinOutreach4

  1. Have you removed the administrative shares on the machine? This Wiki article shows this as a possible cause of the error message that you posted.

    Have you tried the command line method of changing the folder location?

    wdsutil /Uninitialize-Server

    wdsutil /Initialize-Server /REMINST:”Z:\deploymentshare\remoteinstall”

     

     

    For the Invalid UNC path error, can you navigate to that path in a CMD window?

    Does it only give this error when enabling multicasting?

    If you don’t check the multicast box, does MDT accept this UNC path?

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

    The Springboard Series on TechNet

  2. I would recommend the Microsoft Deployment Toolkit (MDT). It is a free deployment solution from Microsoft and is very powerful. MDT can create media for deployment by USB devices or DVD, in addition to being able to integrate with WDS for those systems that can access your WDS server.

    MDT can deploy your custom WIM image easily, but it can be much more flexible and powerful than that. MDT can manage device drivers for hardware independent imaging, install software after Windows is deployed, edit the answer file, name the computer, join a domain, and much more.

     

    These two videos are a great way to show you many of the ways that MDT can make your deployments easier and more automated:

     

    Deployment Day Session 1: Introduction to MDT 2012

    Deployment Day Session 2: MDT 2012 Advanced

     

    There are many more articles, videos and walkthroughs to help you with deploying Windows on the Deploy Windows 7 and Deploy Windows 8 pages of the Springboard Series on TechNet

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

  3. According to the MDT help files, if you set UserDataLocation to AUTO: “The deployment scripts store the user state migration data on a local hard disk of space is available. Otherwise, the user state migration data is saved to a network location, which is specified in the UDShare and UDDir properties.”

     

    You should set UserDataLocation=NETWORK in order to get the file to save to the network location you have specified in the UDShare and UDDir properties. You could use the UNC path (not variables) for the UserDataLocation property, but based on your last post, just changing AUTO to NETWORK should resolve your issue.

     

    Hope this helps,

    David

    Windows Outreach Team - IT Pro

    The Springboard Series on TechNet

  4. WDS has a ‘Filters’ feature to help you manage your drivers specifically for situations like this. You can create filters to make sure that only the drivers for that model are used. The TechNet Article ‘Managing and Deploying Driver Packages’ has detailed instructions that should help you with creating your filters.

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

    The Springboard Series on TechNet

  5. That should not be the case, however the ADK should not be installed on the same machine that the AIK is installed on, as that can cause problems.

    Do these models have Secure Boot turned on? According to the TechNet article ‘Secure Boot Overview’: “The firmware may not trust the operating system, option ROM, driver, or app because it is not trusted by the Secure Boot database”. You may need to disable Secure Boot and possibly change from UEFI BIOS to Legacy BIOS in order to deploy Windows 7 to these machines.

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

    The Springboard Series on TechNet

  6. From what you are writing, it seems that you are doing things in the wrong order. Replacing the boot images in WDS is the last thing that you should do.

     

    1. Edit bootstrap.ini (either in the Control folder of the new deployment share, or by right clicking on the share name in MDT and choosing properties, rules tab, and clicking the button to edit the bootstrap.ini file)

    2. recreate boot images

    3. replace boot images on WDS with new boot images

     

    The bootstrap.ini file is placed inside the boot images during the regeneration process. So you must edit it first, then regenerate, then replace boot images.

     

    In the bootstrap.ini file, you should have a line that shows the path to the new deployment share (DeployRoot=\\Server\share$). The same line should also be in your Rules (which is also the customsettings.ini file in the Control folder).

     

    Just to make sure this is all happening on the proper deployment share, please Close the old share (right click on the share name in MDT, and choose 'Close deployment share'. Then regenerate the boot images and replace in WDS.

     

    Let me know how this goes!

     

    Thanks,

     

    David

    Windows Outreach Team - IT Pro

    The Springboard Series on TechNet

  7. When you recreated your boot images, did you use those new ones to replace the current ones in WDS? Any time there are changes to the bootstrap.ini, the boot images must be re-created and the new ones have to replace the ones in use by WDS. The deployment share location is in the bootstrap.ini file.

     

    Hope this helps,

     

    David

    Windows Outreach Team - IT Pro

    The Springboard Series on TechNet

  8. While it is commonly referred to as the ‘Sysprep limit’ it is actually an activation reset limit. The TechNet article ‘How Sysprep Works’ has a section titled ‘Resetting Windows Activation’ that explains this in detail. To summarize, when Windows starts for the first time, it triggers the activation clock (30 days to activate Windows). So when you install Windows on a reference machine and start it up to customize, you have started the activation clock. When you sysprep this image to capture it, you have used the first reset (specifically, if you use the /generalize switch). Later, if you load your image on to a machine, start it up to run Windows update or update other software and run sysprep again to capture that image, you have started a second activation (when Windows starts) and then you are re-setting the activation when you sysprep to capture this updated image. Windows 7 has a limit of 3 ‘re-arms’ before you have to rebuild the image. Installing SP1 raises this limit by 1. When you have exceeded the limit, sysprep will fail and this support article explains that the image must be rebuilt.

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

    The Springboard Series on TechNet

  9. You can use DISM to inject most updates to an offline image. This article from the ConfigMgrDogs blog on TechNet shows how this is done.

     

    MDT can inject updates during the deployment if you add the updates as packages, or you can set MDT to look to your WSUS server or Windows Update during the deployment to make sure it is up to date. Since you have some versions of Windows that can’t use WSUS, having MDT call Windows Update is probably the best solution for your situation.

     

    Another solution that I’ve seen used is to keep your base images running in VM’s, and when you need to update your image, snapshot the machine, then sysprep and capture. Then you can restore your snapshot to keep the base image from reaching the sysprep limit (which doesn’t exist on Windows 8).

     

    More information about managing Windows is available on the Springboard Series on TechNet.

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

  10. Double click on the failed package name (in the first screen), and you can see details about that package. In those details you will see that this package is unsigned. You can also get more detail on the failure by trying to add the package manually. For example, from an administrative command prompt, use this command and replace “PathToDriver.inf” with the actual path to the driver and keep the quotes around it:

     

    WDSUTIL /verbose /Add-Driver Package /InfFile:”PathToDriver.inf”

     

    For this driver package, it returns:

     

    Error code: 0xC10301B3

    Error Description: This driver package is not signed. X64-based driver packages must be signed in order to be added to the Windows Deployment Services Server.

     

    This is also verified in the TechNet article ‘Troubleshoot Failed Packages’. x64 based driver packages must be signed.

     

    However, it might be possible for you to add the drivers to an offline image using DISM. The TechNet article “Add and Remove drivers offline” has an example of the DISM command to add drivers and uses the /ForceUnsigned switch:

     

    Dism /Image:C:\test\offline /Add-Driver /Driver:C:\drivers\mydriver.INF /ForceUnsigned

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

    The Springboard Series on TechNet

  11. Customizing the image prior to sysprep and capture can be done in Audit Mode when you install Windows onto a reference machine and Windows Welcome starts, press Control + Shift + F3. This will bypass Windows welcome and log you in as the local administrator.

     

    Once you are done making your customizations, use the CopyProfile setting in your Sysprep answer file to make the changes to the local administrator account into the default user profile.

     

    There are many articles and videos to help with deploying Windows on the Deliver and Deploy Windows 7 and Deliver and Deploy Windows 8 pages of the Springboard Series on TechNet.

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

  12. There are a few methods that you can use instead of an answer file associated by architecture.

    You can either pre-stage your clients with a client unattend file, or you can enable the Auto-Add policy to specify that unknown computers require administrative approval, and then you can assign an unattend file upon approval. This TechNet article explains both of these options in detail.

    Another solution is to use the Microsoft Deployment Toolkit (MDT) in conjunction with WDS. MDT is a task based deployment solution, so you can have separate tasks for each OS and architecture that you want to deploy. Within each task, you can have separate settings for partitioning and formatting the drives. It also uses WDS to allow network and multicast deployments.

    There are also many other benefits to using MDT for your deployments. Managing device drivers, install installing packages and installing software (even 3rd party software) during the deployment can all be accomplished with MDT. MDT can also use many other tools during deployments, such as the User State Migration Tool (USMT), the Microsoft Application Compatibility Toolkit (ACT), and more, which come as a part of the Windows Assessment and Deployment Kit (WADK), which is required for deploying Windows 8.

    These great videos show the power and flexibility of MDT:


    Deployment Day Session 1: Introduction to MDT 2012

    Deployment Day Session 2: MDT 2012 Advanced

    Deployment Day Session 3: Deployment using WDS

    More information to help with deployments can be found on the Deliver and Deploy Windows 7 or the Deliver and Deploy
    Windows 8
    pages of the Springboard Series on TechNet.

    Hope this helps,

    David

    Windows Outreach Team – IT Pro



  13. For your first question, PXE booting loads a boot image based on Windows PE. For Windows 7, a new boot image should be created from the version of Windows PE on the Windows 7 disc (boot.wim). Likewise, the capture image should be built from this Windows 7 boot image.

     

    For the second question, this TechNet article states that you must enter a local location to capture the image. This is a requirement that is enforced to avoid image corruption.

     

    One way to avoid the limitation on sysprep is to build your reference images in a virtual machine and take a snapshot before running sysprep. This way you have a non-sysprepped version saved in case you have problems. Another way is to run sysprep with an unattend file that has the skiprearm setting enabled.

     

    Lastly, I would like to suggest that you look into using the Microsoft Deployment Toolkit (MDT). MDT is a common console for many of Microsoft’s free deployment tools. MDT allows your deployments to be as simple or as complex as you need. MDT can manage drivers and updates, install software and much more. MDT also integrates with WDS allowing the use of PXE deployments.

     

    More information about deploying Windows 7 with WDS and/or MDT can be found on the Deliver and Deploy Windows 7 page of the Springboard Series on TechNet.

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

  14. In answer to your question, your current Windows Server 2008 R2 domain controllers can use the Windows 8 ADMX/ADML files to manage your Windows 8 machines. You have to update the Group Policy Central Store on your Windows Server 2008 R2 with the ADMX/ADML files from Windows 8. You can get all the files from the Winsxs directory on your Windows 8 machine, and they need to be copied to the Central Store. This TechNet Blog article explains this process in further detail, and provides the commands needed to copy the files from Windows 8. In addition to the blog post, I also found this TechNet forums thread discussing the same issue, which should also be helpful.

     

    Further information to help you manage Group Policy on Windows 8 (including the Group Policy Settings Reference) can be found in the Managing Settings with Group Policy for Windows 8 section of the Manage and Operate Windows 8 page of the Springboard Series on TechNet.

     

    Hope this helps,

     

    David

    Windows Outreach Team – IT Pro

  15. Since you are still new to deployments, I will ask a basic question… Did you update your deployment share and regenerate the boot images after adding the new drivers to MDT? Any time that you add drivers that would be needed by the Windows PE image, you will need to update the deployment share and while it is not always required, regenerating the boot images will ensure that the changes are applied to those boot images.

     

    I would also like to give you a helpful tip for the log files. Create a folder in your deployment share named Logs. If you put the SLShare setting in your customsettings.ini (Rules) like this: SLShare=\\<servername>\<deploymentshare>\logs (putting in the actual address to your deployment share), then MDT will create a folder for each computer you deploy to (by computer name) and copy all the log files to that location. You can find this setting in the MDT help files.

     

     

     

    David

     

    Windows Outreach Team – IT Pro

  16. Another method to accomplish computer naming during deployment (although not automated) is to set WDS to require administrator approval for all unknown computers, then once they PXE boot they can be named and approved at the same time in the WDS console on the server. This TechNet magazine article shows how this is accomplished. This method would work for the VM's that you spoke of, but for actual hardware PC's, you can pre-stage them in AD and have WDS pull the name from AD.

     

    Hope this helps,

    David

    Windows Outreach Team - IT Pro

  17. My first recommendation is to use WSIM (Windows System Image Manager) to create your unattend files. This will make it easier for you to create your unattend file properly, as it has a validation feature to ensure that the file doesn’t have syntax errors. WSIM is a part of the Windows Automated Installation Kit (WAIK).

    When comparing your client unattend file to an example file (found here) shows that you are wiping the disk, but you are not creating new partitions. When the element ‘WillWipeDisk’ is set to True, the existing partitions will be removed. The createpartition component is needed to setup the partitions before the modifypartition can format and label.

    You also do not have the language/UI settings in this file, so it will not choose the language for you. Example 1 on the page of example files has the correct component and elements needed for the language/UI settings.

     

    Since you are going to be imaging a large number of machines, my second recommendation is to use the Microsoft Deployment Toolkit (MDT). MDT allows a greater amount of customization in your deployments with several great features. The ability to add updates to MDT that are injected upon deployment aids in keeping your images up to date without loading the image on a machine, updating, sysprepping, and re-capturing the image. Another great feature is the ability to install software after Windows is installed with post-installation tasks. This keeps the software out of your image so that any updates or new versions can be configured in MDT without touching your image. You can also create software groups to automatically deploy software needed per department, rather than a one-size fits all image that needs modification after deployment. WDS can use the images you create in MDT to deploy through PXE booting and multi-casting. Here is a short video walkthrough of setting up MDT and populating the deployment environment which should help you get started.

     

    Hope this helps,

    David

    Windows Outreach Team - IT Pro

  18. According to the TechNet article that you linked, unsecure join tries to join the domain without credentials. Set unsecurejoin=False and then it should use the credentials in the unattend file to join the domain. So, your unattend file is trying to join the domain without the credentials being used. This TechNet article should help clarify that for you, and points out that if you are intentionally using unsecurejoin=True, then you do not create the settings for Username, password and domain under the credentials section.

     

     

    I would also like to add that the Microsoft Deployment Toolkit can be a great help with deploying Windows Operating systems. You do not have to set things like domain join in the unattend file, because you set it in the task sequence in MDT and MDT passes the information into the deployment process for you.

     

    Hope this helps,

    David

    Windows Outreach Team - IT Pro

  19. Paul,

    I was referring to the boot options. When you turn on the computer and get it to network boot, the options for booting can be either 32 bit WindowsPE or 64 bit Windows PE. The 64 bit Windows PE will not display 32 bit OSes for deployment. If you can see your 32 bit Windows 7 image, then that is not the problem.

     

    However, you should be fine with using the LiteTouchPE_x86 boot image once you have the custom XP image imported to MDT and you create the task sequence for it. Let us know how this works out for you.

     

    David

    Windows Outreach Team - IT Pro

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.