With a good autounattend, now have to move to Office Setup

English: M in blue square (similar to seen on )
English: M in blue square (similar to seen on ) (Photo credit: Wikipedia)

Desktop Support in the raw (boring!)

One of the many things I would set about doing at my old job was getting things updated to install new Windows/Office disk images for rebuilt or newly built desktops and laptops. One of the first tasks was to build a from scratch WIM from the base install media (Win7 install.wim and the Office 2010 Pro .iso disk images) Now I want to customize the OCT (Office Customization Tool) and get the Office 2010 install just right for a first install on a newly rebuilt system. I’ve played with the OCT in the past, but there’s also an unattend.xml file one could use instead. Might go that route now that I got the Win7 setup running under autounattend.xml (no more OCT)

One thing that is making this XML learning process easier is the edit xml, install test build, observe failures and re-edit round trip is an Oracle VirtualBox I’ve got installed. I’m using the Win7 Setup .iso as a mount point within Virtual Box. It is the first CD drive. Then I have the autounattend.xml sitting in another .iso which I mount as the secondary CD drive. That combo forces the Win7 setup to ‘see’ the autounattend.xml file and start customizing the install as it goes along. One of the cool utilities included with the Windows Automated Install Kit (WAIK 3.1) is a command line program called oscdimg, it will create a .iso out of any folder you choose. That’s what I do to create that secondary CD mount point in VirtualBox. And I never once have to change it, all I have to do is create a new .iso every time I edit the autounattend.xml file (each just adding or deleting a comma and I can start all over again without reconfiguring the VM!) This has saved me countless hours of attempting to do this on real hardware (which is absolutely unnecessary in this case) until I can get it just right.

And let me say there’s a lot of ground to cover and barriers to entry before you can get it ‘just right’. Some of the features provided in Autounattend.xml don’t work. Literally hands down, attempting to add a trusted zone in IE during the Win7 Setup process doesn’t work. And better yet, there’s discussion board entries that CONFIRM it doesn’t work. I’m so glad people participate in these company sponsored fora for the whole world to see. I’m so glad, I didn’t beat my head and heart out trying to get this one ‘feature’ nay, ‘bug’ to work properly. There are a multitude of other ways to achieve the same goal, so I’m pursuing it doing the Copy Profile = true route and add the Trusted Zone URLs to my admin profile let that become the default profile on the machine. Then capture the whole kitten-ka-boodle using Sysprep/GImagex on that idealized Dell Optiplex 960 with all drivers persisted. That’s going to be my universal WIM to start out with. We’ll see how close I can hit that mark.

As it turns out I did go through a number of revisions of this disk image until I perfected it by Feb. 2013. Then I updated the drivers and patches and so forth in June to come out with a grand final WIM for doing all the desktops, laptops for my old office. Since then I had to turn this work over to a contractor who just got hired full-time. He’s now got an updated WIM file using the Virtual Box as a kind of Virtual Build Lab for both updated, creating and applying the WIM images. That work then allows us to put it onto a WinPE flash drive and apply it as needed for a full-touch manual image of a computer. I’m still holding out hope that this can be improved and  be less manual, less high-touch than in the past. One further refinement along those lines was adding a “drivers path” to the Windows unattend.xml file. That allowed us to robocopy the drivers for a particular machine into a known folder path on the newly imaged machine (no matter which one it was) and it would just suck up all the drivers on the OOBE steps on the first/second reboots after the machine was imaged for the first time. Heady stuff and I have to say once you start tweaking it speeds stuff up a lot and it just works! It never breaks or wrecks the process. So it’s very reliable to make those single changes that take a step out of the (re)imaging process.

I’m still playing around with these ideas and have trained my replacement on how to use them. Next steps are Windows ADK 8.1, WinPE5 builds and coming up with an image with Office 2013 and Win8.1. I think that will become our next reference standard before long.







3 responses to “With a good autounattend, now have to move to Office Setup”

  1. winoutreach2 Avatar

    One thing you might want to try alongside the Windows ADK for Windows 8.1 is the Microsoft Deployment Toolkit (MDT). MDT is the recommended method for Windows deployment and builds on the technologies you have outlined above, but offers improvements in automation and functionality. For one example, the driver injection process you describe is entirely automated. Simply import the drivers into the Deployment Share and MDT can sort out which drivers apply when you deploy the image. It also helps by providing automatic generation of deployment media (ISO) and can even, when installed on a Windows Server with Windows Deployment Services (WDS) deploy over the network via PXE boot.

    All said, it can greatly speed up piloting and customizations in your virtual environment and when you are ready, it can be used to deploy your next reference image directly into production.

    Video of Windows 8 Deployment with MDT:

    Windows Outreach Team- IT Pro
    The Springboard Series on TechNet

    1. carpetbomberz Avatar

      Thanks Brandon for that reply. I’ve never gotten the full MDT install into production. In part the biggest single barrier was a large number of post imaged apps that needed to be installed for custom builds. We had always hoped to get some base level imaging capability running within MDT. But could never get to the point where we could start doing the “silent installs” of all the various and sundry apps folks need in addition to their regular MS apps. Some of those older legacy apps don’t really have a silent install option. So since we had to do things in a high-touch kind of way, doing things by hand seemed like it was almost the same effort.

      However, things are looking up. We do have a big SCCM management infrastructure already in place. If we do decided to start building on top of that, we may not need to spend time/effort getting MDT into production. But eventually I think we’ll still hit that wall of lack of “silent installs” to automate the building of the custom desktops. Some of those legacy apps also get installed within the XPMode/Virtual PC environment which further complicates the steps and makes it much less automated. But it’s nice to know still what promise MDT holds, if we just had the time to get it going properly.

      1. winoutreach2 Avatar

        That is great that you already have SCCM up. MDT integrates excellently with SCCM to control the Windows deployment component while SCCM manages drivers and applications. See the ZTI deployment documentation:

        Applications like that without silent installs can be a bit difficult, but you can get a good head start on the applications that can be installed then resort to the high touch method for the remaining apps to finish up the environment. Of course the ultimate goal is to get the applications to install via Task Sequence and be completely automated. SCCM will be a big help in that department while MDT manages the images and Windows deployment.

        Windows Outreach Team- IT Pro
        The Springboard Series on TechNet

%d bloggers like this: