Shivering on the 49th Parallel
Wednesday, 19 January 2011

I started out the task flying pretty high. I worked on a deployment for some new HP laptops and Windows 7 Pro x64 and things were working out as planned.

Once I got it to where I could PXE boot the laptop, connect to the deployment share and lay the Windows 7 x64 image down on it, I was time to get down to the nitty gritty: Drivers. Applications. Packages. Automation.

Drivers were fairly easy, I’ve been importing them for awhile now, but what I wanted to do was to segregate them into distinct little piles, rather than one motherlovin’ huge pile of inf files and I wanted a computer to only get the drivers it needed for itself, not the whole lot of them.

MDT 2010 provides for this, and there are plenty of good tutorials out there on the net waiting to be found, so I won’t “waste ink” posting it here again. I highly recommend you use the Readability bookmarklet before going to any of the articles on that site, though. They have ads and crap on all 3 sides and a narrow column in the middle with small text for the actual article.

So we got a bare-bones Windows 7 install at this point, with a bunch of Unknown Devices in the Device Manager. Windows 7 is smart enough that most of them have drivers advertised through Windows Update so right-clicking them and selecting “update driver” will find it… but that’s not why we’re using deployment tools, I want it to come out the other end of my process shiny and clean and ready to be used. Following information in those links above and elsewhere, I was able to have WindowsPE detect the make & model of the laptop, and then look that up in my deployment database and download the drivers I specified. Awesome! All but one… one sticky wicket that wouldn’t work because the manufacturer chose to make the driver file a software installation, instead of just a driver. (hate)

On to the Applications settings in MDT 2010 then! Applications don’t work as well as the drivers do. There’s no Selection Profiles for applications like there are for Drivers. Sure you can set MandatoryInstallation <guid> in the customsettings.ini file for the whole deployment share, but then they get installed on every machine that connects, not just the one laptop model that needs this particular driver, so that’s out, too.

Searching around on this topic led me to the Make & Model settings under Advanced Settings>Database. I created a new entry using the Make and Model of the laptop using the data I got from the BIOS. To find out what yours is, drop to a command prompt and type ‘wmic csproduct get vendor’ or get name. Once you’ve created an entry, you can double-click it to open it’s properties and assign things like Applications, Roles and Administrators. Applications is the one we’re looking for here so I clicked on that tab and then clicked Add. I then selected the Driver software.exe that I had set up (as a silent install… another topic!) and then clicked OK. I updated my deployment share and… it didn’t work.

I tried a few different things, I checked, double-checked, and triple-checked that I got the Vendor and Name correct, I tried moving the application around within the deployment share, but nothing worked. Because I was working with a physical machine, it took about 30 minutes to test out each iteration. While it was doing that, I opened the ZTIGather.log on my virtual machine that I had deployed to yesterday, which is in C:\Windows\Temp\DeploymentLogs and using the Vendor and Name in there, I created another entry in the database and assigned it a very small application (most of the apps I have in the repository are huge… Autocad, Office, etc.) to try that one out. I updated the deployment share and this time, just in case, I also went into Windows Deployment System and replaced the boot image with this newly generated one.

I booted the VM up, let it PXE boot, selected x64 boot image and stepped through the Wizard and when I got to the Applications screen… Holy smokes it was there! pre-checked! I tried un-checking it and then clicked next, but then went back and it was re-checked, so it was treating it as a mandatory application, but only on that make & model of computer! I then rebooted the laptop into the same x64 boot image to see if it was working for my original problem. If it wasn’t, at least I had proved that it wasn’t an error with my database. I flipped through the screens to Applications and the driver was there and pre-checked! Hooray! hurried through the rest of it and let it deploy. Once it got to the Windows 7 desktop and the last stages of the deployment were running, it installed the driver software. I rebooted (windows update kicked in right away) and when it restarted, I checked out the device manager: Nothing was showing as Unknown Device! Hooray! One machine down, 2 more to go, get a few more apps in there and my MDT 2010 deployment share will be ready to kick out the Win7 Pro x64 jams to all comers! (well, within my company and licensing agreement, anyway) Open-mouthed smile

Wednesday, 19 January 2011 16:57:01 (Pacific Standard Time, UTC-08:00) | Comments [0] | Deployment | Microsoft | Servers | Windows#
Wednesday, 18 August 2010

I’ve written before about what a huge, horrible, steaming pile of horse shit you have to wade through to install a 32-bit (x86) driver on a 64-bit (x64) server. It’s SO counter-intuitive it makes me want to scrape my eyeballs out with a grapefruit spoon and then chop off my fingers so I won’t be able to see a computer or type ever again.

In a nutshell, you need to have a 32-bit client running Vista or Windows 7, install “the full meal deal” printer driver on that client, THEN connect to the 64-bit server’s printer share (\\server\printer) and then tell it to use the existing driver. That will then UPLOAD the driver from the client machine to the server and make it available to other 32-bit clients who try to connect to it.

Today I’m in the opposite situation. I PURPOSELY set up a 32-bit Windows Server 2008 (not R2, which is 64-bit only) to run my print queues because 99.9% of my network is 32-bit Windows XP clients and I didn’t want to have to go through this rigmarole for every single one of them. *MY* laptop, however is running Windows 7 Professional 64-bit and it’s unable to connect to the shared printers on the 32-bit server.

Rather than duplicate the steps above, since I was feeling saucy and experimental, I went the other(old) way around. On the 32-bit server, I opened the printer properties, went to the sharing tab and clicked on Additional Drivers. I checked the 64-bit box and it asked me for a driver. I clicked Browse. I navigated to the folder where I had the 64-bit driver .inf file for the printer, selected it and clicked OK.

Fast-forward a few seconds and the window closed, and the box was checked. Just like that. Just how it USED to be in older versions of Windows Server. I went back to my laptop, tried to connect to the printer, and this time instead of failing and saying “Driver Unknown” or even worse, the  0x0004005 error which is one of the more generic error codes you’ll ever see. (I always thought it was “Access Denied”, but that’s just ONE of the errors it COULD be.) Up came a NEW dialog box. Do you trust this printer driver? Yes, of course I do. Just like that, it mapped the printer, using the 64-bit driver on the 32-bit server.

If it’s so bloody easy to do that with a 64-bit driver on a 32-bit server, why the HELL is it SO difficult and bass-ackwards to do it on a 32-bit driver with a 64-bit server??

Wednesday, 18 August 2010 10:09:35 (Pacific Standard Time, UTC-08:00) | Comments [0] | Tech | Deployment | Hardware | Microsoft | Networking | Servers | Windows#
Wednesday, 17 March 2010

There are a lot of blogs, classes, tutorials, how-tos, workshops, links and opinions on how to best deploy Windows 7 using the new Microsoft Deployment Toolkit 2010. What there’s a distinct lack of is how to make these tools work with XP which most of us are still using. I am planning to move to Windows 7 x64 later this year, but we have a software dependency on 32-bit Windows that we have to get past first (and no, Windows XP mode won’t cut it for this app)

I spent most of yesterday downloading software and patches. the Windows Automated Installation Kit 2.0 (which supports Win7, 2008 R2 and back to XP) was a 1.7gb iso file which took a couple hours.

Eventually last night I was ready to start the capture of an existing Windows XP box that I could then deploy to the other new machines.

This morning I tried to do it and it failed. I assumed it was permissions-based since the error was 0x00004005 which I know from past experience is “Access is denied”. After sorting that out, it still failed. Trolling through forums from a Google search, I found some people were able to get it to work by using the IP address of the deployment server, or sometimes the FQDN, rather than just "\\server\share$”

I rebooted, opened Windows Explorer and navigated to \\192.168.x.x\share$ and when it asked me to authenticate (because this is a workgroup computer and the share is a domain resource) I entered my credentials and then I double-clicked the litetouch.vbs script to kick off the imaging process. This time it seemed to work, it downloaded the WinPE files needed, ran sysprep and then rebooted to capture the image… except that’s when it failed.

Digging into the winpeinit.log I saw that there’s no NIC. Awesome. Great. I figured that the driver for the NIC would be part of the Windows image, but I overlooked the fact that the WinPE boot-time would also need the NIC in order to connect to a network share and create the disc image there, and the new machines would need the NIC driver to connect to that same share and copy the image down to the local computer.

No biggie, except that the computer is now stuck in a loop booting into WinPE rather than back into Windows XP. I injected the driver for the NIC into the deployment share’s Out Of Box Drivers and rebuilt/updated the deployment (which also adds the NIC driver to the winpe.iso file). All that’s left to do now is to PXE boot the machine which will download the new winpe (now with more NIC flavor) and start over… except now my PXE server isn’t configured properly :p

Wednesday, 17 March 2010 11:27:45 (Pacific Standard Time, UTC-08:00) | Comments [0] | Tech | Deployment | Microsoft | Networking | Servers | Windows#
Search
Archive
Links
Categories
Admin Login
Sign In
Blogroll
Themes
Pick a theme: