locked
WinPE Drivers for VMware Workstation 11 RRS feed

  • Question

  • Hi,

    I am trying to use VMware Workstation 11 to create a master image for distribution by MDT 2013/WDS. I've added the VMware drivers to the deployment share and configured it to inject drivers by the detected platform, "VMware Virtual Platform." Each time I try to capture an image, it takes forever... Forever, I mean days, until the process times out and fails. I added the VMware Tools to the VM, and set the NIC to bridged mode (1Gbps). This time, the capture wizard takes an additionally long time to complete. When it reboots into Windows PE, I get an error message.

    File: \Windows\System32\drivers\pvscsi.sys

    Status: 0xc0000359

    Info: The operating system couldn't be loaded because a critical system driver is missing or contains errors.

    Pvscsi.sys is a VMware driver. Surely, I cannot be the first person who has tried to use Workstation 11 as a tool to create master images for MDT 2013. How can I fix this driver issue? I'll try disabling the driver in MDT, but that kind of defeats the point of having them there in the first place. I am trying to create an image of Windows 7 Professional x64.

    Thanks in advance.

    Jason


    Jason

    Tuesday, June 30, 2015 12:19 PM

All replies

  • I don't know if you have a separate deployment share for creating reference images already, if not I'd make one. Then configure that deployment share to inject all drivers (default) instead of using the driver management method. By using a separate deployment share you not only keep anyone from using the wrong task sequence but you can configure that deployment share to be much more automated and geared towards creating reference images.

    Or you could use Hyper-V which comes with Windows 8 or Server 2012 R2, but I'm sure you'd like to stick with VMware.

    I'm not sure what VMware defaults to, but you could speed things up by giving the VM at least 4GB of ram and 2 virtual processors.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, June 30, 2015 1:54 PM
  • I disable pvscsi when I load VMWARE drivers, it's never created an issue for me.  As for your speed, that's always been dictated by my network speed. Where are you capturing to, your host machine?  Network storage?
    Tuesday, June 30, 2015 2:46 PM
  • I really don't have the hardware to run Hyper-V. My desktop is a Windows 7 computer and my server runs on desktop hardware. I'm not even considering touching Windows 8. I already have two deployment shares on my MDT server, a third does not sound like a great idea. How automated can you really get when capturing a deployment? I just run the litetouch.vbs file from within the OS I want to capture and the task does the rest (usually). Lately, though, I haven't been able to capture anything due to the horrendous speed. I tried using a different network port on a different switch, and that has seemed to provide better results. Disabling pvscsi.sys allowed the task to boot into Windows PE. I am capturing to a physical server on its own gigabit connection.

    Thanks


    Jason

    Tuesday, June 30, 2015 3:09 PM
  • I have three deployment shares on a desktop machine running Server 2012 R2, Hyper-V and SQL. I don't have performance issues, besides a deployment share doesn't do anything when not in use since it's just a shared folder so space is the only real concern. Well not using Windows 8 is your choice, we have 152 systems and climbing on Windows 8.1. Once we reimage or replace another 20 machines, we'll break the 50% mark on Windows 8.1.

    As to the automation, I can run a single task sequence that builds and captures a reference image. I just boot to the litetouch iso, choose my ts, enter the name of the wim file that I want the image saved as and away it goes, it'll even shutdown when it's done. I can keep the customsettings file in that deployment share all geared towards automated image creation.

    But whatever workflow works best for you.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, June 30, 2015 3:50 PM
  • It sounds as if you sysprep the computer, shut it down and, reboot it to WinPE, then run a capture. I have to configure the default user profile extensively with our images, so a deploy-install-capture approach won't work for me. I'd be interested to hear more about your approach to capturing images.

    Changing the port used fixed the speed issues for me. 

     

    Jason

    • Proposed as answer by iam_srk Monday, July 6, 2015 10:09 AM
    Tuesday, June 30, 2015 5:02 PM
  • Oh I configure things too, I just have a suspend task. Much of the configuration is automated because I made some scripts and added them to the task sequence. But I still suspend it so I can shutdown the VM and make a snapshot. Then I later rollback, run windows update, shutdown make another snapshot and continue the sequence so it captures it again with all the updates.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, June 30, 2015 5:28 PM
  • Here's an example of my TS that builds a reference image. Also I'm the only one with access to the "Admin" share so no one else can mess with the sequences or accidentally deploy them.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, June 30, 2015 5:32 PM
  • Why are you injecting VM drivers into a master image that you'll use on physical machines? Are you deploying to physical machines? Have you tried removing the drivers? Why are you installing VMWare Tools? What are you backing up to? In the four years I've been working with MDT and VMs I've never once add an issue. I use VMWare 10 Server 2012 r2 ( has worked with 2008 r2 ) And I can deploy and capture Win 7, 8.1, and 10 with no issues Please configure your customsettings.ini to capture logs Remove the drivers Remove process of installing VMWare Tools Use the option to fully recreate your ISO Replace ISO in WDS Test it and see what it does While in the capture stage, press F8, see the performance and networking tabs. While the image is being captured my VM CPU is @ 100% My physical machine is a core i7 with 32 gigs and 2 - 256 GB SSDs My Win 7 VMs get 3 processors and 4096 of ram
    Thursday, July 2, 2015 7:19 AM
  • Many times I am deploying into VMware just to test something. I am not necessarily always making a master image. I don't have adequate supplies of modern hardware around to test with all of the time. I'm not necessarily installing the VMware tools either. I just want the VMware drivers to be available to Windows when I deploy there. When creating a master image, I start with the Windows install ISO and leave MDT out of the equation. CustomSettings.ini is set to capture all logs to my server. My physical development machine runs Windows 7 Professional x64, 16GB of RAM, VMware Workstation 11 on a 1TB rotational HDD. I know it is not great, but it is what I have and that is all I have to work with. I have been trying to squeeze an SSD out of the budget for a while now. Thanks

    Jason

    Friday, July 3, 2015 12:31 PM
  • Don't feel bad, I run Hyper-V on my own all-in-one desktop which has Windows 8.1, 16GB RAM and 500GB 5400rpm drive. It wasn't until last week that my boss finally got me a 960GB SSD. My secondary MDT server is running on an OptiPlex 980. I usually just work on one VM at a time. Point is you don't need high end hardware to make good use of MDT, in the end the biggest difference maker will probably be the speed of your network connection when you deploy.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Friday, July 3, 2015 1:00 PM
  • Again why the drivers lol?
    That should be plenty of hardware to capture a 30 gig image in an hour. At my old work, I'd capture a 25 gig file in 45 mins to a spindle drive What is the lan speed of the computer that hosts your share?
    What about VM ( by default they should be a gig)
    Does it route through anything that's not 1 Gig?
    Like Dan said, your lan speed is the most important factor in this.

    Saturday, July 4, 2015 4:42 AM
  • Sorry if I am repeating what is already stated- can't read such a big thread entirely :)

    build the image from somewhere else. Like from a physical or a hyper v VM. dont worry about drivers- sysprep anyhow is going to clean up all the drivers before it captures. this is also the probably reason why you get the error when you boot into winpe. 

    we have seen a lot of problems like this and easiest solution from it will be to capture the image from elsewhere. I typically recommend hyper v as you can capture the image without installing any software/driver etc in the image. 


    Mayank Sharma Support Engineer at Microsoft working in Enterprise Platform Support.

    Sunday, July 5, 2015 9:19 AM
  • Sorry if I am repeating what is already stated- can't read such a big thread entirely :)


    Mayank Sharma Support Engineer at Microsoft working in Enterprise Platform Support.

    Not to be rude but, the fact you say those quoted words; makes me wonder why even say anything?.  Since you're on an MDT team

    Second point, that was my next suggestion try Hyper-V or Oracle's free solution Virtualbox

    Sunday, July 5, 2015 8:48 PM
  • When creating a master image, I start with the Windows install ISO and leave MDT out of the equation.

    Jason

    There's no reason to leave MDT out of the picture when building a master image. In fact I wouldn't want to build one without it and I started off like you. Using MDT to build your master image is not only faster and easier but it will ensure nothing is missed if you automate your configurations/modifications. Just about anything you need to modify can be done with a script/batch file and then added to your task sequence that builds your master image. Add in a suspend task, shutdown the VM and then make a snapshot while suspended. Now you have clean build. You can boot it back up and make any other manual modifications you need to. If it's Windows 7 you can modify your administrator profile in order to use copy profile when you deploy this image. Trust me once you go down this path you'll wonder why you ever built images w/o MDT.

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Monday, July 6, 2015 12:58 PM
  • I'm starting to see this. It is easier to create images that way, except my suspend task is not working. MDT is just skipping over it and failing at the end. The WSUS integration is nice.

    Jason

    Monday, July 6, 2015 6:27 PM
  • What's going wrong with your suspend task? It should be added as a "run command line" and the command should be

    cscript.exe "%SCRIPTROOT%\LTISuspend.wsf"

    Double check to make sure the "disable this step" checkbox is not checked.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Monday, July 6, 2015 6:36 PM
  • That's what I have. It just stops after the first Windows update step. I'll try again to get the exact error message.

    Jason

    Monday, July 6, 2015 10:55 PM
  • Hello,

    Not sure if anyone else mentioned this already and if so I'm sorry for the duplication...

    The fact that you're getting errors about the storage driver puzzles me and lead me to ask, when you setup your guests, did you customize storage to use a SCSI adapter or something other than the default?

    I use VMware Workstation 11 as well and it works great for me; I don't inject any drivers into the reference build and the most I have ever had to do was edit the VMX file so that the NIC emulates the Intel e1000.  

    In my lab environment the server and the capture VM are both on the same Host-Only network.  We do something similar for our production images, the server and capture VMs are both hosted in vSphere.  I've had to start adding more hardware resources to the VMs to accomodate WSUS integration but outside of that within a few hours I have an image.  

    Tuesday, July 7, 2015 12:27 PM
  • I'll pull the VMware drivers out of MDT. That seems to be the general consensus. Now, I just have to get that suspend step working in my task sequence!


    Jason

    Tuesday, July 7, 2015 12:37 PM
  • Here is the error message I am getting at the end of the deployment.

    MDT Error

    The BDD.log specifically shows "Litetouch deployment failed, Return Code = -2147467259 0x80004005. Googling the error message does not bring up anything close to what my experience is. Has anyone else seen this?

    Thanks 


    Jason

    Tuesday, July 7, 2015 1:48 PM
  • Take a look at the scripts folder in your deployment share. Do you see the LTISuspend.wsf file? Does your command line have quotes in the right place so that the path will be correct? Can you paste in a screenshot your TS where you have the suspend task.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, July 7, 2015 4:09 PM
  • I have the script and found a typo in my task sequence (I missed the trailing %). I'm re-running now to see if that is the issue. Thanks


    Jason

    Tuesday, July 7, 2015 4:51 PM

  • Not to be rude but, the fact you say those quoted words; makes me wonder why even say anything?.  Since you're on an MDT team

    Second point, that was my next suggestion try Hyper-V or Oracle's free solution Virtualbox

    Because I am an expert in MDT, I work with very closely the product group of MDT and have more than 8 years of experience in IT and over 5 years of supporting MDT and have access to resources that no one outside have. So unless you are here to sing holy gospels- I am the right guy to solve a problem in MDT. Not 'yours' obviously since you are too rude. 

    Mayank Sharma Support Engineer at Microsoft working in Enterprise Platform Support.

    Saturday, September 12, 2015 10:05 AM