Getting started with Microsoft AutoPilot

Microsoft AutoPilot is a new way of deploying software to Microsoft desktops - and will hopefully replace the more traditional imaging based deployments.  Why?  Pretty simply, it allows end users to re-provision their machine whenever needed back to corporate standards.

Getting started from an administrative perspective is pretty straight forward, but as you would expect there are a few hoops to jump through in order to ensure your devices are registered for AutoPilot -- AutoPilot uses a hardware hash to match a machine to your "allowed" deployment targets, and as such, if you do a motherboard swap etc you will need to update your AutoPilot configuration.

Lets get started.


First step you need to get the csv file prepared for an existing (or multiple) machines. The easiest way to do this is this script:

So do an Install-Script -Name Get-WindowsAutoPilot in a elevated PowerShell prompt on the machine in question, followed by a Get-WindowsAutoPilot -OutputFile c:\temp\file.csv.

This will create a csv file with your hardware id and has ready for upload.


Next step, enroll for AutoPilot -- login at, click Manage from the top, then scroll down and select Windows AutoPilot Deployment Program.

Click on Groups, Add Devices and specify the CSV you created earlier.

If you haven't created a deployment group yet, you will be prompted to give it a name. This is a logical grouping to help you target configuration and software; not that to move devices you need to delete them from AutoPilot and re-add them to the correct group.


Next, you need to create a profile - click AutoPilot Deployment and selection Create New Profile. Fill in the settings as you wish - note they are limited here to simple Windows behaviours, but I'll show you later how you can tailor your environment further. Once you have created your profile, tick your device(s) from the list and select AutoPilot Deployment > Apply ... profile name ... .

If you get stuck here, checkout the documentation.


Note: There's also an AutoPilot section under Microsoft Intune; this is where you can (and will) do further assignment of things, but you will find that if you originally add the devices through the Business Store they will not immediately appear in Intune.  Simply click Sync in the Intune UI and it will pull the updated device list through.

Mac OS X and the constant Time Machine backup prompts...

After upgrading my iMac from Sierra to High Sierra, I started getting a lot of really annoying popups from Time Machine along the lines of "This mac hasn't been backed up in 416 days".

Yeah, I know. I turned you off you silly thing ...

I HAD been using TimeMachine to backup to my Synology NAS, but ended up turning it off when I moved everything into the most excellent Microsoft OneDrive - so why was it nagging me now?

Turns out there is a bug in High Sierra (yeah, shocking isn't it), it was now complaining at me as the target volume was not available - turns out you have to get it to "forget" the target volume, otherwise it will nag you even though its disabled.

To do this, go into System Preferences, Time Machine, and right-click on the ICON for the drive.

And there you go, peace at last!

Malware testing using Cuckoo

This afternoon I decided it was time to update my Cuckoo malware analysis setup, and while I was at it, I figured it would make sense to write it up in case anyone else wants to create one !

Cuckoo Sandbox is a superb project, but as with all technical open source ones it can be a bit fiddly to get running.

I first start off with a clean Kali Linux installation, and ensure that it is fully patched (apt-get upgrade / apt-get dist-upgrade). After that, install the pre-requisites for Cuckoo: 

apt-get install python-pip python-dev libffi-dev libssl-dev
python-virtualenv python-setuptools libjpeg-dev zlib1g-dev swig

apt-get install mongodb

apt-get install virtualbox

apt-get install tcpdump apparmor-utils

And then some config tidy up:

setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump

Now, you should at this point create a user for Cuckoo, but you can (not advisable!) continue and run it as root.

adduser cuckoo

usermod -a -G vboxusers cuckoo

Install the required Python modules

pip install -U pip setuptools

pip install -U cuckoo

You need to load the current community definitions up by running this command

cuckoo community

And then its time to setup the actual virtual machines the malware is analysed in.

Start VirtualBox: virtualbox at the console.

Then File > Preferences, Network, Host-only networks.
Create a new network - this will create the default vboxnet0 network

Create a new VM; in my setup I started with Windows 10. Connect the CD-ROM through to your installation media and complete your install as you would normally.

Install Python 2.7 and Pillow; Install the agent as documented and ensure that you start it as Administrator. 

On your Kali machine, you need to edit the virtualbox.conf file as appropriate (you will find this in $HOME/.cuckoo/conf). I changed mode = gui instead of headless as I like to see whats going on, and then scrolled down to the cuckoo1 entry and changed the label to match the name of the VM I'd created, set snapshot to CuckooBase and then changed the osprofile as appropriate. Make a note of the IP address assigned while you are here.

Back in VirtualBox, ensure that you are on Host Only networking (on vboxnet0) and set the IP Address on the adapter in your virtual machine to be the IP address from the virtualbox.conf file. Subnet will likely need to be

Take a snapshot of the machine powered on and in this state, and call it CuckooBase.

And now you are ready to use the Cuckoo setup!

At a console type cuckoo submit <file> to submit the analysis job, and then cuckoo to run the process.

There is a LOT more you can do with Cuckoo, and this is really the only very basic steps to get a working environment, but it should give you a good starting point!

Office 365 - UK Data Residency deadline

Microsoft recently announced the deadline for current Office 365 user's to request relocation of their data to their UK Azure data centres.

To do this, a service administrator should login to the Office 365 portal, select Settings then Organization Profile.  Scroll down and you will find the Data Residency option box where you can now elect to have the data residing in the UK.

The deadline for requesting the move is 15th September 2017, and the move itself will apparently be completed within 24 months of the above deadline. That's a fair wait!

It should also be noted that this only applies to "Core" data that will be moved - although finding clarity on that particular topic is challenging.  More details can be found here.

Upgrading lab to Server 2016

As Server 2016 is now in GA, I figured I'd have a shot and upgrade my lab from 2012 R2 to 2016.

The majority of the machines were completed as an in-place upgrade.

Before the upgrade:

- AD Server, also holding ADFS and WSUS (server core)
- Applications Server (full fat desktop)
- SQL Server (server core)
- Web Application Proxy (server core)

After the upgrade:

- AD Server (server core)
- ADFS Server (full fat desktop)
- Applications Server (full fat desktop)
- SQL Server (server core)
- Web Application Proxy (server core)

All 2012 R2 boxes were fully patched before upgrading; ADFS was split out onto a seperate box as the upgrade is not capable of an in-place upgrade of this element - the process as documented here is fantastic for migrating this. I still haven't installed WSUS again but I'm planning on rebuilding the SCCM element of my lab anyway, so don't need it yet.

The only snag I've encountered is that when you do the in place upgrade for server core, you need to run Setup with a couple of parameters - /Compat IgnoreWarning - otherwise you just get a blue screen.

The Web Application Proxy server upgraded fine, but the WAP component was left in an invalid state; I just removed it and reinstalled as I was resetting ADFS anyway -- likewise Azure AD Connect needed to be reinstalled and reconnected.

Finally, a disk cleanup frees up space - just run 
dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
although it should be noted this will prevent you reverting the upgrade etc.

Next task is to upgrade the two Hyper-V hosts for my lab ...

Windows 10 - Remote Desktop - Login Failed

I've been getting an error that has been bugging me recently on my Windows 10 device - a Surface Pro 4 running the Fast Ring Insider build (at this time its Build 14342_rs1_release.160506-1708).

Trying to Remote Desktop to a Windows Server 2008 just wouldn't work -- not matter what combination of credentials I tried, it just failed with a 'Login Failed' error. Oddly, connections to other machines running Server 2012 DID work. I shrugged it off and ignored it until I got time to look at it today - and the fix amazes me.

Simple enable the Firewall exception for Remote Desktop -- fire up firewall.cpl, click allow a program through the firewall, and select Remote Desktop. Reboot, and that's it.

Must be something getting blocked around the authentication or such. But at least that's working again.

Office 365, MDM

I was experimenting with Office 365's offering of InTune last night - and made an interesting discovery.

Don't just enable it. You'll find you lock out your user's devices from accessing resources until you "fix" the policies. The default policy seems to be that any device access a 365 resource must be enrolled into the Organisation's InTune account. Probably not a bad thing, but might not play nicely with companies if you have other MDM's deployed, such as Cisco Meraki or VMWare's AirWatch. Guess I'll need to do a bit more testing here.

To disable the policy and regain access, visit the InTune page at:

Then go to Security Policies, Device Management.

Edit the Default MDM Policy by Office 365.

I think you now have two choices: Disable the Deployment or add an exclusion. Personally I did both until I work things out - Deployment, set to No, and click on the Manage Organisation Wide Device Access Settings to get to the exclusions option (I added the Default group here - which basically disabled intune!).

Office 365, Azure AD and LiveID accounts

Recently a company that I deal with has moved to Office 365 -- this has entailed moving a number of identifies into Microsoft Azure AD (think Active Directory, existing on Azure and usable for SSO activity) and signing up for Office 365 services.

No problem - or so you'd think.

When trying to signin on a Microsoft site with an enrolled Organisation account (that is, an account on the Azure AD), the OLD LiveID was being used intermittently. A quick chat with Microsoft confirmed this -- Organisation and LiveID's can exist on the SAME email address at the same time - surely a situation where it can lead to confusion!

The good news is you can disable / deactive your LiveID to drop back to just using the Org account (where possible at least), but it does mean you have to be careful during the deactivation period to ensure you sign in at the right place (best to use addresses!).

However, the world gets a bit murky if you are using MSDN it seems:

Am I the only one that can see this being a total nightmare for companies with a large dev population or other LiveID usage?


Surface Pro 4 - Impressions

For the past few weeks I've been using a Surface Pro 4 -- something I picked up just before I headed to San Francisco for Microsoft Build 2016.

Why did I opt for the Surface Pro 4 over the Surface Book? I already have a very functional laptop (an Macbook Pro actually), and I wanted a tablet that was actually a functional device (and I could handwrite on!). The Surface Pro gave me more bang for buck in this regard.

It's even powerful enough to let me play Prison Architect ;) (And, of course, run a small dev lab in HyperV)