Woooo love it when IBM takes down the forums mid day for maintenance.
Could someone give me the long and the short of the OS Deployment and what this new MDT Media Creator is and what it means for Bare Metal install?
In the past I had created an image and uploaded it to the TEM server and managed to deploy it out, but the profile did not carry and the resolution was set to 1024X768, just like the PE. But I somehow broke that server and had to rebuild it, so I lost all my work.
Currently we build a master image with Windows 7 x64 and install all of the software and drivers we need and customize it to our needs. Then once this is complete, I have a custom answer file for sysprep that we use, once it has syspreped, we PXE boot it to a Ghost server and upload it.
Then when it is time to image an area, we pxe boot all of the machines and deploy the image out, come back hit ok, then name and join them to the domain.
I understand that the way TEM OSD works, it allows me to push the image and keep it joined to the same domain and with the same name. I have no idea how the new Media Creator works for Bare Metal. That is our only concern. How do we image bare metal machines.
The MDT Media Creator works in the same way that the MDT Bundle Creator works (which is the tool used to generate the deployment share used with our Capture and Re-Image features).
After you fill out the parameters.ini, and are happy with all the settings, the media creator will generate 3 things:
An MDT Deployment Share
An ISO image that you can then burn to a DVD (if the ISO is small enough to fit on a DVD).
A folder containing all the items you would need to move onto a bootable USB stick.
After you’ve burned a DVD or moved the required files to your USB stick, you now have a tool that can be used to to image a computer from any state.
I have MDT installed, I have a bundle created, I have WAIK and 7-Zip installed. But when I go to upload the MDT Bundle, it just spins saying “Uploading MDT Resource. Please wait…” It was like this for about 18 hours with no change. Any thoughts or suggestions?
It looks like something went wrong during the upload. Go ahead and cancel and try again. If you run into the same problem report back and I’ll give you some debugging information.
Ah okay. Sorry to hear you’re running into trouble. We wrote a tool called uploadmanager.exe that, when run, will leave behind a log file. Can you attach a zip of the most recent 5 logs that you find in the directory: %TEMP%\OSDeployment. They will be called something like uploadmanager_1234567910.log
Another bit of information that might be important. Is there anything special about the connection between the console machine and the server. Proxy in place, etc? The uploadmanager.exe is somewhat of a dumb tool and it might be getting confused by such things.
That’s extremely unfortunate that no logs exist. I’d recommend opening a bug so that we can devote some developer time to working on this issue and so we can work more closely to diagnose the issue.
I had this same issue when uploading. I was not able to spend much time on where the problem was, but I use the provided fixlets to install .Net, 7-Zip and MSXML on the system I was running the console to upload.
I’m sorry that you had trouble with the uploading. We do have intermittent issues with the tool that does the uploading sometimes but have a hard time reproducing. Sometimes as with you, something just needs to restart (dashboard, console, or server).
A lot of times it takes some interactive sessions to see if we can determine what is going on so we can make fixes for the future. Usually restarting the dashboard or console solves the issue but sometimes not. It obviously depends on the connection from console to server, but it really shouldn’t take that long (small packages a few minutes, large WIM images, ~20 minutes in background). This all depends on disk/computer performance and network connection of course. If you think it’s not going, you can check task manager on the console and look for uploadmanager.exe. Logs should be generated as we said before %temp%\osdeployment and should be constantly updating while upload is in progress. If dashboard is still uploading but uploadmanager.exe is not, something went wrong and you should restart the dashboard (CTRL+F5) and try again.
So now the question is, what am I doing wrong with the PE drivers?
I downloaded the PE driver pack from Dell and pointed the OSD to that and when the PE starts to boot, it has no network connection and when I check the logs I get this:
Property LogPath is now = X:\MININT\SMSOSD\OSDLOGS LiteTouch 7/9/2012 3:39:10 PM 0 (0x0000)
Just to be sure we’re on the same page – are you attempting to use Bootable Media – or are you using the Re-Image dashboard to attempt a re-image?
Here comes the obvious question, did you remove the media from the device (hence the prompt)?
Please zip up all log files you have and attach here.
Also, what does your parameters.ini look like (the one you used to generate your bootable media content) if you could include that in the zip also, that would be helpful?
Any customizations? Anything special about the system on which you’re deploying (i.e. multiple partitions/disks?)
I am attempting to capture an image using the “Capture Images” from inside the Systems Lifestyle.
I have a laptop next to me with our fully customized image. I modified the sysprep to suit our environment but kept all the important parts of it
The way I get that error, is that it drops out at a command prompt when it enters PE. I run the LiteTouch.wsf manually and it gives off that error.
When I run ipconfig, it comes back blank, so I know it is not getting network drivers. I have uploaded 100+ drivers for all the systems. And even pointed the PE drivers to a PE Driver folder provided by Dell. Under Drivers > Make (Dell) > Model (E6520) it shows 14 drivers including E1c6032.inf and E1C62x64.inf and bcmwl6.inf for Net under Class.
I have attached the logs from the 9th.
here is the Parameters.ini. I have a Windows 7 x64 listed in the MDT Resources
general
MDTBundle and DeploymentShare directories will be created beneath this target
target=C:\BigFixOSD
overwrite=yes
debug=0
network
This section specifies certain network connection parameters, needed to download USMT 3.0.1
#proxy=
#proxyUsername=
#proxyPassword=
mdtsources
This section specifies the locations of sources that will be used to create the DeploymentShare/MDTBundle
waiklocation=C:\Program Files\Windows AIK\
Location to the USMT 3.01 MSI files. If not provided, these will be downloaded.
;usmt301x86location=
;usmt301x64location=
Needed for capturing Windows XP x86
#windowsXPx86media=
Needed for capturing Windows XP x64
#windowsXPx64media=
Needed for deploying Windows Vista x86
#windowsVistax86media=
Needed for deploying Windows Vista x64
#windowsVistax64media=
Needed for deploying Windows 7 x86
#windows7x86media=
Needed for deploying Windows 7 x64
windows7x64media=L:\Source Files\Windows 7 Pro x64
Given that you’re doing some sort of customization, I think we need a bit more information to know what is going on.
How are you modifying sysprep? Are you still running the complete Capture action created by the Capture Images dashboard. If everything in that multiple action group is not executed correctly and in order you can have issues. One of the actions is to download and inject the drivers into PE.
If that is indeed running correctly, and your customization is not interfering with anything, one check is to see if the drivers for your computer model are for PE. Check to see that network and disk (scsi,hdc,…) are for Win7 x64(PE). You can check/uncheck the filters in the Driver Library dashboard to see which drivers are for that make/model for Win 7 x64 to be sure that we will inject into PE those drivers.
Error looks like it might be related to not finding disk. In PE can you try navigating to c: or d: to see if you have disk drivers. More logs on the machine can be found (c\d\x):\windows\temp\