Monday, 12 February 2018

Migrate to Microsoft Intune from another MDM solution

Customers have asked me about this many times. How can we easily migrate to Intune from another MDM solution? Therefore I've decided to test drive a tool that I heard about recently. EBF have developed a tool called the EBF Onboarder and it supports the migration to Intune from pretty much all the well known MDM vendors. You can read about it here

It's really easy to use.



So let's start with the source MDM solution. You can see that I have a device waiting to be migrated.......



......and this is the EBF Onboarder. Click on New Migration to start.



Enter a name for the migration. Be creative.



Now we're asked to choose the source MDM system. The following solutions are supported sources:
  • Blackberry UEM
  • MobileIron Core (VSP)
  • MobileIron Core (EAS unmanaged)
  • MobileIron Cloud
  • AirWatch
  • XenMobile
  • Good for Enterprise
  • SAP Afaria
  • MaaS360
  • Sophos Mobile Control
  • Cisco Meraki
  • SOTI MobiControl
  • jamf PRO

Enter credentials for the source system. 



Microsoft Intune is the default target system. Enter your credentials. We only need to enter the tenant ID if the user has access to multiple tenants.



Click Find Devices.


EBF Onboarder connects to the source system and lists the device(s) that we need. Click Save Migration


Confirm that you want to Save the migration project.



You are presented with the content of the migration email that will be sent to users. This can be customized. Save the email.....




...and here is the migration. Check the box beside the users name and you can then select Send Invitations. This is so simple to use.

Now lets have a look at the behaviour on this Android device.


The user receives the invitation from EBF Onboarder for Intune.


The user opens the email and clicks on the Start Migration link.


The user is re-directed to the Onboarder service and asked to select Start Migration.



The first step is to retire the device from the source system. It's alarmingly quick (approximately 30 seconds).



Retirement is complete and now the user in invited to enrol with Intune. They are instructed to follow the Microsoft Intune link.



The user is re-directed to Google Play store and asked to download and install the Microsoft Intune Company Portal. We're familiar with the rest of the process at this stage.



User authenticates with Intune.........



.....and continues with the setup process.



The device is being added to Intune.



Enrollment is complete.


The device is available for management in the Intune portal.

The two-step retire/registration process on the device took less than five minutes and was very straightforward for the user to understand and follow. I was very impressed.

You can sign up for a trial on the EBF website The trial allows you to migrate 20 devices from multiple source systems and only expires when the 20 have been migrated.

I hope you found this blog post interesting. Until next time.........

Thursday, 8 February 2018

Failed to publish package to WSUS

I had a funny problem on a customer site today while deploying a Flexera CSI solution for third party patching. I integrated the solution with WSUS but had problems creating the agent package. The package failed to be published to WSUS.


The error was: Failed to publish package. Code: -2147467259. CreateDirectory failed.

Now I'm familiar with this error from my experience with System Center Updates Publisher. It's usually a permissions issue and that the logged on user does not have permissions to create a new folder in the UpdatesServicesPackages folder. Permissions was a good place to start troubleshooting.

I checked the NTFS permissions on the UpdatesServicesPackages folder but all looked normal
  • Full Control: Administrators, SYSTEM, WSUS Administrators
  • Read, Write: NETWORK SERVICE
  • List Folder Contents, Read, Read & Execute: Users/Everyone
I then thought I'd verify that my user account was in fact a member of the local administrators group on the server. That looked a bit weird. My user account AND SID were listed. That didn't look right to me so I figured that I needed to look into the health of the server.

I ran the PoSH cmdlet test-computersecurechannel and the result was worrying

Operation failed. Unknown interface.

Mmm, now I was getting a little concerned. Next step was to check the services and I found the little problem. The Workstation service was stopped (I have no idea how or why). Starting the service solved the problem and all was good again.


I could successfully create the package.

I hope this helps someone who encounters a similar problem. Until next time.....




Tuesday, 16 January 2018

Video training series "Manage ConfigMgr Internet clients with the Cloud Management Gateway"

I'm very pleased that TrueSec have just published my video training series 

Manage ConfigMgr Internet clients with the Cloud Management Gateway

There are five videos in the series:

Introduction to the CMG
This video is an Introduction to the Cloud Management Gateway. Previously when we wanted to manage ConfigMgr clients over the internet we would use Internet-based client management. This was a good technology with many advantages. However, there were also some disadvantages. Now we can use Cloud Management Gateway to manage these clients. It consists of a Microsoft Azure cloud service and a ConfigMgr site system role that communicates with the Azure service. Clients can then use the Azure service to communicate with ConfigMgr.
This is cool technology and gives us many advantages over traditional internet based client management.


Prerequisites for the Cloud Management Gateway
This video describes the general requirements for the successful implementation of a CMG solution. This includes specific ConfigMgr requirements and the certificates required for Cloud Distribution Point and Cloud Management Gateway.


Certificates for the Cloud Management Gateway
This video is all about certificates. These are the tasks that admins find the most difficult. We’ll be creating the certificates necessary for the configuration of the Cloud Distribution Point and the Cloud Management Gateway.


Configure the Cloud Management Gateway
In this video we will create the Cloud Distribution Point and Cloud Management Gateway. Then we’ll add the Cloud Management Gateway Connection Point.
Finally, we’ll configure the Management Point and Software Update Point to allow CMG traffic.


Managing clients with the Cloud Management Gateway
In this video we’ll have a look at a Windows 7 client and see how the behaviour changes when the client moves from the intranet to the internet. We’ll deploy software to the internet client. Finally, I’ll show you a couple of tricks that should be useful for your deployment.


I hope you enjoy the videos. Thanks to Johan Arwidmark and the guys at TrueSec.

Until next time......

New Intune features for Apple device management

I'm pretty busy at the moment with management of Apple devices using Microsoft Intune. Therefore I was particularly interested to see the new developments in this area in December.

Jamf Pro Integration

Jamf Pro is a very popular tool for the management of Apple devices (Mac, iPad, iPhone). 
  • Deployment
  • Device Management
  • App Management
  • Inventory
  • Self-service
  • Security
We can now integrate Intune and Jamf Pro. If your organization uses Jamf Pro to manage your end users' Macs, you can now use Microsoft Intune compliance policies with Azure Active Directory conditional access to ensure that devices in your organization are compliant.

Shut down iOS devices

This is a new iOS device action. We can now shut down iOS 10.3 supervised devices (immediately without warning to the end user).

Install Office apps on macOS devices


A new app type now allows us to install Office apps on macOS devices (Word, Excel, PowerPoint, Outlook, and OneNote).


Delete an iOS Volume Purchasing Program token

We can now delete the iOS Volume Purchasing Program (VPP) token using the console. This may be necessary when you have duplicate instances of a VPP token.


You can read about these and the other new features released in December in the What's new in Microsoft Intune doc site.

I'm looking forward to using these features over the coming weeks.

Until next time.....



Monday, 6 November 2017

My experience with Windows 10 AutoPilot - the good and the bad


I've just configured Windows 10 AutoPilot in my test Azure tenant and enrolled my first devices. It's really easy and the experience has been mostly very positive. I had one issue which actually turned out not to be a technical issue but I'll get to that a little later on. 

What is Windows AutoPilot? The official Microsoft definition is as follows:

"Windows AutoPilot is a collection of technologies used to setup and pre-configure new devices, getting them ready for productive use".

It's actually the Microsoft equivalent of Apple's Device Enrollment Program (DEP) for those of you familiar with managing Apple devices in the corporate world. The idea is that a user can take delivery of their new Windows 10 device and join it  to the organizations Azure Active Directory in a matter of minutes without having to complete all the annoying setup screens. Also the user does not have to end up being a local administrator on the device, as used to be the case with manual Azure AD Join (unless you want the user to be a local administrator of course, which is doubtful).

This is all part of the Microsoft modern management story. Traditional management typically leverages technologies such as Active Directory, Group Policy and ConfigMgr to provide deep manageability and security. Make no mistake, this is set to continue. Modern management is a more simplified approach using cloud-based solutions like Microsoft Enterprise Mobility + Security (EMS), which includes Azure AD Premium and Intune. It’s complemented by cloud services like Azure Information Protection, Office 365 and Microsoft Store for Business. Windows 10 offers the flexibility to respond to these changing requirements, and can easily be deployed in a mixed environment in areas like provisioning, authentication and configuration management.

At a recent event I was asked about modern management and the scenarios in which it was useful. I didn't give a particularly useful answer at the time but I've had time to reflect on the question since. In my opinion modern management is useful when you don't particularly care too much about the device. It's all about the data and access to corporate resources. For remote users that primarily use Office 365 the modern management scenario is ideal. Access to corporate resources is managed and controlled by Azure AD and Intune conditional access and data is protected by Azure Information Protection policies. Don't get me wrong, we can still manage the devices to a high standard using Windows 10 Configuration Service Providers (CSPs) although these are a subset of what can be managed using traditional group policy objects (GPOs).

So back to Windows AutoPilot, the steps to configure the solution are as follows:
  1. Prerequisites
  2. Hardware ID
  3. Add devices to tenant
  4. Assign AutoPilot deployment profile
  5. Windows 10 configuration via CSP (optional)
  6. User turns on device and signs in
Step 1 - Prerequisites
  • Devices must be pre-installed with Windows 10, version 1703 or later 
  • Devices must have access to the internet
  • Azure AD Premium P1 or P2 licenses
  • Microsoft Intune or other MDM services to manage your devices
  • Azure AD configured for Intune autoenrollment (note that Windows Autopilot is not supported on Intune hybrid at this time, although it "may" work).
  • Devices must be registered to the organization (we'll do this in step 3)
Step 2 - Hardware ID

This step involves harvesting hardware information from your Windows 10 devices and uploading this information to your tenant in advance. This hardware information includes the device serial number, the Windows Product ID and the hardware hash in CSV format. As usual there are a number of ways to gather the information and upload. 

Note: I've gathered the hardware information manually from a VM in my lab for the purposes of demo. In reality, from early 2018 we won't have to do this in production. The main hardware vendors have signed up (or will sign up) to participate in the Windows AutoPilot program. This means that they will provide this CSV for each device that they ship directly to users. There are also plans to allow the vendors to upload this information  to your tenant on your behalf. Watch this space.

I've chosen to create the CSV file using a PowerShell script provided by Microsoft. See here for a description of the script. It's in the PowerShell gallery so you don't have to download and install it. It installs automatically when you execute it from the PoSH console (run as administrator).

Execute the script: Install-Script -Name Get-WindowsAutoPilotInfo



Accept the warning about the path environment variable change.



Allow the NuGet provider to be installed.



Allow scripts to be run from "PSGallery".



The script is available in C:\Program Files\WindowsPowerShell\Scripts



Set the execution policy so that you can run untrusted scripts.


Execute the script: .\Get-WindowsAutoPilotInfo.ps1 -ComputerName <ComputerName> -OutputFile .\ComputerName.csv



The CSV file has been generated and can be found in the C:\Program Files\WindowsPowerShell\Scripts folder.



This is the format of the CSV file. You can see the device serial number, the Windows Product ID and the hardware hash.

Step 3 - Add devices to tenant


Now that we have generated the CSV file we can add the device to the tenant. We must do this in the Microsoft Store for Business.

Note: Even though we can create AutoPilot deployment profiles in the Intune portal we cannot add devices at this time. If we want to use Intune profiles we must add devices to the MSfB and sync to Intune.



Select "Manage".



Select "Devices". Click "Add devices". Navigate to the CSV file and add the device to a deployment group when prompted.



Device is added to your tenant.

Step 4 - Assign AutoPilot deployment profile

There are two options for this. We can create deployments profiles in either the Microsoft Store for Business or the Intune Portal (in Azure).

Option A
Open the MSfB and navigate to Manage > Devices



Click on AutoPilot deployment and choose Create new profile.


Enter a name for the profile and select your required settings.


Select a device or a number of devices and apply a profile.



These devices are now ready to go.

Option B
Open the Intune Portal in Azure.


Select Device enrollment.


Select Deployment Profiles.


Choose Create Profile.


Enter a profile name and choose the join type - Azure AD Joined. Edit the OOBE settings.


Select your OOBE settings. The options are the same as those in the MSfB.


The AutoPilot deployment profile has now been created in Intune and can be assigned to devices. Where do the devices come from though? I can't add them directly in Intune.


In the Intune Portal, navigate to Device enrollment > Windows enrollment > Devices.


Click Sync to synchronizing devices from MSfB.


Select a device and choose Assign.


Select the AutoPilot profile you created earlier.


The device is ready to go.

Step 5 - Windows 10 configuration via CSP (optional)

This isn't really part of Windows AutoPilot but is very much part of the modern management story so is worth a mention. We can configure some Intune plicies using Windows 10 Configuration Service Providers and these will apply to the devices once the are joined to Azure AD and enrolled in Intune.

It's very straightforward to create and deploy a CSP policy. Read more about CSPs here.


In the Intune Portal, navigate to Device configuration.


Choose Create Profile.


I want to disable Bluetooth on my devices. Enter a name and choose the platform and profile type. Select Configure.


Name: Disable Bluetooth
OMA-URI: ./Vendor/MSFT//Policy/Config/Connectivity/AllowBluetooth
Data type: Integer
Value: 0

Save the policy......


....and assign it to your users.

Step 6 - User turns on device and signs in

I have two VMs for testing. The one of the left is the one whose hardware details have been uploaded to my tenant and assigned a Windows AutoPilot profile (it has been reset). The one on the left is just a regular Windows 10 v1709 VM.


Select your region.


Select your keyboard layout.


Do you need a second keyboard layout? So far so good.


Now the VMs connect to the internet for updates. The VMs have an Ethernet connection. Otherwise I would've been prompted to join a wireless network. Remember that an internet connection is required.


....and here we go. The Windows AutoPilot deployment profile has been applied to the VM on the left. 

Look at the differences:
  • my tenant name appears on the autopilot VM (I cheated here - see below)
  • I don't have the option for "Domain join instead" on the autopilot VM. I have to enter my Azure AD credentials in order to continue.
------------------------------------------------------------------------------------------------------------

Slight cheat:

I spent quite a while trying to figure out how to get my tenant name to appear as shown above. I kept getting a "Sign in with Microsoft" screen and as a result thought that the autopilot profile did not apply. All the Microsoft documentation and demos showed this and it turns out that this is misleading. Damion, Mayank and Maciek from Microsoft helped me to understand that this customization is not actually part of the autopilot profile. 

I figured out that this comes from the Company Branding feature of Azure.


You don't really have to configure it very much. The status just can't be "Not configured".

-------------------------------------------------------------------------------------------------------------

So let's carry on with the user experience.


Enter the password.


Windows sets up the devices.


We don't have to choose privacy settings on the autopilot VM.


We must configure Windows Hello (requirement of our tenant).


MFA kicks in (note that the user is walked through the MFA setup process if they haven't already completed).


Set up Windows Hello PIN......


....and we're done. Now let's examine the two VMs.


Both are joined to Azure AD but I don't have administrator permissions on the autopilot VM.


This is verified by looking at the local administrators group.

(Note that if the user is a global administrator on the tenant they will be a local administrator on the device, regardless of the AutoPilot settings).


See my optional CSP configuration. Bluetooth is disabled on both devices with no possibility of turning it on. I've shown another computer with Bluetooth enabled for comparison.

Summary

Overall this was a brilliant experience. Windows AutoPilot is a dead cool technology and still a work in progress. However there are a couple of things requiring a little more work.
  1. We're still not able to add devices directly into Intune. We have to add to MSfB and sync to Intune.
  2. You cannot remove devices in Intune. The facility to remove devices is available in MSfB but I had some difficulty and got the error message "Try that again. Some of the devices weren't removed".
  3. Devices cannot be renamed in MSfB or Intune.
  4. The Microsoft documentation is very misleading and I wasted a lot of time as my tenant name didn't appear on the sign-in screen. It turns out that this was to be configured using Company Branding, not AutoPilot. I would like to see Company Branding enabled with default settings as soon as an autopilot deployment profile was created.