OneDrive for Business Next Gen Sync Client ConfigMgr Detection Method

Recently the OneDrive for Business Next Generation Sync Client was released. This new client brings the OneDrive sync feature out of the Office suite and into a standalone product. I'm not sure if it supported by Microsoft, but you can have both the Office integrated OneDrive for Business client and this new Next Gen client running at the same time. One of the key features missing from the Next Gen client is that you can't sync a SharePoint library using it. You can read all about the features and nuances of the client in Microsoft's post.

The installation files can be downloaded from this site http://go.microsoft.com/fwlink/p/?LinkId=248256.

Detecting the install

The installation for the new client is pretty straight forward so I'm not going to go into detail there, create a new Application, select a script type installer and run "OneDriveSetup.exe /silent" as your Installation Program. In my testing I was able to get the new client installed without any trouble (I tested on Windows 7 only, I'm not sure if my results are applicable to Windows 8, or Windows 10) using "OneDriveSetup.exe /silent" as my installation command line. You'll notice that this installation does not require administrator rights to run, nor does it show up in Add/Remove Programs. Instead the OneDrive application is installed to the user profile directory of which ever user ran the installation, it installs to %LOCALAPPDATA%\Microsoft\Onedrive\ , this also means that the installer will need to be run for each user who logs into the computer that wants to use this version of OneDrive. Given this information I thought I could use a file type detection method by using the path of %LOCALAPPDATA%\Microsoft\Onedrive\ and file name OneDrive.exe.

Seems simple enough, right? However this ends up with a failed install. Why? Because this detection rule runs in System context, regardless if you chose the "Install for User" or "Install for System" installation behavior. I was stuck on this for a while, after some searches I found that others have run into similar issues and discovered that if you run a script based detection method that it runs in the user's context if you choose install for user. I then configured a PowerShell script based detection method and used the command "Test-Path $env:LOCALAPPDATA\Microsoft\Onedrive\OneDrive.exe".

This cleared up the detection issue I was having and I was getting successfully installations when installing from the Application Catalog.

This by no means a comprehensive way to deploy the new OneDrive client, you might want to do some things like remove the old client, prompt your users to log into Office 365, or other things that would smooth the transition from the previous OneDrive client to the Next Gen client.

Dynamically Set Hostname in SCCM Task Sequence

You may be in a situation where you need to dynamically set the hostname of a machine as part of your SCCM task sequence. For a zero touch deployment you'll want to use a method that requires no interaction. In my experience I've found that using the serial number of the machine provides a decent unique string. 

A note about Windows hostname length. On some forums the maximum size of a Windows hostname is a debate, however I find it best to stick to what Microsoft has published on their site, 15 character maximum and a restriction on some special characters. https://support.microsoft.com/en-us/kb/909264

Know what platform you're deploying to

In order to support both physical and virtual platforms I set up most task sequences with separate rules to accommodate physical and virtual machines.

Separate task sequence steps are used based on the target platform 

Physical Machines

Each Name Workstation has a different condition associated with it, for example the Name Workstation (Physical) step will only run if the system mode does not equal "Virtual Machine". 

Uses the task sequence variable %SerialNumber% as the hostname

This step only runs if the task sequence variable Model does not equal "Virtual Machine"

For workstations I like to use only the serial number of the computer which can be accomplished by just typing %SerialNumber% into the Value: box. Most manufactures use a unique string that is fewer than 10 characters, however you should take some samples in your environment first, below is a screenshot of a home built PC that I use, I believe it is an ASRock motherboard. You can see what the serial number of a machine is by opening a PowerShell prompt and typing "Get-WMIObject Win32_BIOS"

On a home built system the serial number is not populated

VMWare Virtual Machines

VMWare VMs are a different beast, they have very long serial numbers that contain spaces. See example below

Because of the long serial number what I like to do is just take the last two characters and prefix it with "VM-" (obviously this gives you less entropy, but I haven't found the need to image many VMWare machines yet). You'll see in the screenshot below you can do some basic string manipulation using VB script syntax, we're taking the right most two characters from the %SerialNumber% task sequence variable, then adding "VM-" to the beginning.

To ensure this step only runs on a VMWare virtual machine I use the following criteria.

Hyper-V Virtual Machines

Hyper-V is similar to VMWare where the serial number is going to be long, however the format is a bit easier to work with.

Hyper-V serial numbers are 32 character string with dashes

For Hyper-V I take the rightmost 8 characters of the serial number and prefix that with "VM-"

In order to ensure this only runs on the Hyper-V platform I use the following conditions

Final Thoughts

There are many ways to accomplish the task when you're working with computers. Hopefully these examples put you on the right track for a task sequence that can accommodate your needs. Comment on this if you know a better way of doing it, I'd like to hear how others are accomplishing this.