Software Deployment to Barely Connected Users

In a world where high-speed Internet connections are ubiquitous, even laptop computers can be expected to have some form of regular connection to the Internet or corporate network. However in the past few months the same scenario has cropped up in conversations with customers: How to include computers that barely connect to corporate network, in mass software deployments such as Office 2010. And to further complicate matters, when they do connect it's remotely over the Internet and with extremely slow connections.

 If the devices had access to a relatively fast internet connection we could simply make a distribution point available to them either using Native Mode in ConfigMgr or allow clients access across the corporate VPN.

 So the question is how to deploy to these machines. As an admin you are left with one of 4 options:

• 1. Recall the laptop and install manually
• 2. Utilise mobile engineers to install the software
• 3. Remotely talk the user through installing
• 4. Manually deliver the content on a disk, but install using ConfigMgr

With a bit of work we can implement number 4 to hopefully reduce the on-going administrative effort for specific deployments.

 My solution takes the responsibility of delivery from outside of ConfigMgr whilst allowing the installation to occur automatically and still within the Local System context to overcome any permissions issues.

 The first step is to create a package without any source files. Simple enough!

The second step is to decide how to ship the content to user. Again, simple enough, you send the user a DVD or a USB flash drive with the content on.

Now is where the complications start:

• How can you guarantee the location of the content once the user has plugged in or inserted the disk you send them?
• Different computers may have different numbers of hard disks, some with CD Drives, others without.
• The user may have also created their own mapped drives.

In a nutshell, not all computers will have the same drive letter available. This means you can't create a program to run the content from the D drive, or the E drive, or the F drive, or the.... (well you get the idea)

To get around this, we will use a script to ensure that the same package, program and advert can be used on every machine we deploy to.

For efficiency sake it would be great to not have to copy the content, and in Windows 7 and Windows Vista we could make use of MKLINK to save copying the content. However, given Windows XP's on-going popularity I'd be remiss not to consider deployment to such devices.

Unfortunately, I can't think of a platform agnostic method other than copying the content to the local disk.

Next is to script this copy. My script of choice is the good old Batch File. All that is needed for this is one line and the XCOPY command:

XCOPY <source> <destination> /ecyiq

For my testing I am deploying Office 2010 Professional Plus to Windows XP SP3 clients. And my distribution medium is a DVD. I create a batch file 'InstallOffice.bat' in the root of my source disk with the following line:

XCOPY Office2010 "c:\temp\Office2010\" /ecyiq

By using a relative path for the source, when the script is initiated from the root of the content drive the folder will be copied. Thus sidestepping the inconsistent drive letter issue I discussed earlier.

Step 3 is to create the program, as you normally would; in my case I created the program with the command:

"C:\temp\Office2020\setup.exe" /adminfile "C:\temp\Office2020\fullunattendedsetup.msp"

Step 4 is to advertise the program. It's best practise to limit the collection to those clients you wish to target to reduce unnecessary policy evaluation and to reduce the risk of users running an advertisement that will fail because no content is available. Not to mention it will skew your reporting if you target your entire estate, 99% of which will be able to download content and there have Office deployed in a more traditional manner!

Create a non-mandatory advert and target the program at your client collection!

This is enough to deploy the software, the user can run the bat file to copy the content and then go into the 'Run Advertised Programs' applet in the control panel.

NB Make sure that the targeted machines have received the policy before you ship the content disk to the user. The pre-defined report "Status of a Specific Advertisement". Clients showing "No Status" have not received the policy and those showing "Accepted" are good to go!

However a few more steps will ease user experience and reduce the input and effort required on their part.

The Configuration Manager 2007 SDK has an example of a script on how to initiate an advertisement. We can make use of this by including the script on the content disk we send the user: https://msdn.microsoft.com/en-us/library/cc143667.aspx

And the only amendments I make are to declare the variables 'programID' and 'packageID' and set them according to the values of the package and program I am deploying. I save this as InstallOffice.vbs to the same directory as the content and the batch file. To automate this I add the following line to the batch file:

Wscript.exe "InstallOffice.VBS"

Now all the user has to do is insert the disk and run the batch file and as long as the policy has been downloaded then the install will proceed.

There is one final step we can do to automate the whole end to end process, and that is to distribute the content on a CD or a DVD and use an autorun.inf file to automatically begin the copy and install when the disk is inserted.

My 'autorun.inf' looks like this:

[autorun]

ShellExecute=InstallOffice.bat

icon=Office.ico

label="Office 2010 Distribution"

The root of my DVD now contains the following files:

Now when the user receives the disk all they have to do is insert it into their machine. The install will either begin automatically or the user will receive an autorun prompt with the option to run the installation.

Deployment success can be seen in any of the usual ways:

Immediately from the 'Run Advertised Programs Applet' :

And also from the Site once the client has been able to send status messages:

And from the reports node:

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

This post was contributed by Rob York, a Premier Field Engineer with Microsoft Premier Field Engineering, UK.