We have been doing migration’s from some old Windows 8.1 devices to Windows 10, We couldn’t do a direct upgrade as the devices where going from 32 to 64bit and needed to reformat the disk to UEFI.
We needed to migrate the users data as to limit the manual work for each device so decided to use User State Migration Tool (USMT).
It’s been a few years since I had to use USMT so thought it would be good to do a post on using USMT.
First I went through the Microsoft USMT documentation.
https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-technical-reference
https://docs.microsoft.com/en-us/windows/deployment/usmt/understanding-migration-xml-files
We are using MECM 2002 and have installed ADK 1903 which has USMT version 10.
Since the disk is going to be wiped and reformatted we wont be able to save the state to a local partition so we will need to use the state migration point to save content too.
First step is to install and configure state migration point in MECM.
Open the MECM console and go to Administration > site configuration > server and site system roles and select or add the server that will be used as the state migration point
Set the max free space in MB, GB or percentage. we also need to set the boundary group that this state migration point will be associated with.
Once the role has been installed we can start to create the task sequence to wipe and reload the device.
We won’t go through creating the TS from scratch in this post.
First step is to check is the capture state task. 
By default USMT will use the MigApp.xml and MigDocs.xml to set what will be copied.
To view the xml files you can go to the Windows ADK install location the default location is:
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\User State Migration Tool\amd64
We will be using the default xml but you can create custom xml’s to customize what files and setting need to be copied and restored.
To set the custom xml select customize how user profiles are captured and click on the files button to add in the xml files. 
Once the TS is setup we just need to deploy to a collection so that devices can be added and pick up the wipe and reload TS. 
Once deployed either wait for the TS to be picked up or run the client action machine policy and app deployment evaluation. 
We can check the smsts.log file to view what is happening we can see below that the files are being downloaded for the USMT package. 
Once the scanstate kicks off you can see the xml files that are used in the log. 
We can check the USMT folder on the state migration point to see if data is being copied. 
Once the image is applied, we can check the restore state task in the smsts log. The command will call the loadstate and cause use the default or custom xml files. 
When the TS has fully finished we can logon to Windows we should see that the devices is running Windows 10 and also has the file and settings migrated.
To read an XML report in PowerShell you can use the typecast to XML by using [xml] in front of the variable which should make querying the content easier. 
This is what the export will look like.
Give the applications a name and sign in to Azure using a account with the required permission 
I just left user discovery enabled. 
Click next to finish configuring the Azure services. 
Once finished the Azure service should now be showing 
The Azure AD tenant should also show with both application we just created. 
I left the alerting as default 
Just follow the wizard to complete. 
To allow the software update point to communicate with the CMG, tick the allow configuration manager cloud management gateway traffic. 
After this has been configured the clients should now pick up a the CMG as a internet based management point in the network tab of client agent properties. 
Copy the code and click on the enter code hyperlink and enter the code
We can also now connect to the VM using integrated RDP console in WAC
To confirm the query is working we can create a search filter for all software updates to make sure they match.
Last step was to create a weekly email report using SQL Server Reporting Services (SSRS).
I created a custom Reports folder to keep any report I created.
Follow the report wizard to finish the report creation. 
Once the report wizard completed the report builder should load. 
First create a new dataset. Right click on Datasets > Add Datasets
Once that click ok and the dataset should show under datasets. 
Select the dataset we create.
I just wanted to use all values so drag all row to the value box.
Next just go through the rest of the wizard. Once completed you should see something similar to the below. I added a text box at the top for a tile and added in some grey filling on the table. 
Now save the report and we can run from the MECM console to see what the report will look like. 
Last step is to create subscription to send a the weekly report 
Select report delivered by Email and put in the required detail and report to be included.(Email settings need to be configured in SSRS before you can select email as a deliver option)
Set the schedule that is required and complete the wizard. 
The report should now be sent out weekly as a csv file.
Accept the terms.
To add a server click Add. 
Click search active directory and put in the server name. 
When connecting to servers, to allow single sign on there is an additional command that need’s to be run. If this is not done you will see the below warning when connecting.
The above command adds the admin server to the below attribute. 
Once this has been done when you click connect it should now use SSO. 
Once the workspace has been created we need to configure the on-premises connection account. 
Put in details for the domain account, I used a service account that has read access to AD so that I could restricted the logon to the account to only be used for ATP 
Once AD details are added next step is to download and install the sensor agent. Go to sensors and download the setup exe and copy the access key as this will be required during the install. 
Copy the installer to the DC and run. 
Select required language. 
Deployment type will be sensor I am running on VMware and this will generate the below warning which will redirect to a guide to disable IPv4 TSO Offload. 
This is where we need to put in the access key so that the sensor is associated to the correct workspace. 
The agent should now start to install. 
Once the agent has install it can take some time for it to respond in Azure ATP.
Now the agent should start to notify of any suspicious activity that run’s like reconnaissance on SMB, DNS and other malicious reconnaissance.
We can also add sensitive account and group, there are default groups/ accounts that are considered sensitive by default like Administrators, Domain admins, Enterprise admins…, a full list of these can be found in the below link.
If we now logon with the HoneyToken account it will then alert the activity by this account. 
We can also run reports or schedule reports for schedule reports. To run a report go to the reporting blade and change the date to the range you want and click download. 
Below is an example of the modification to sensitive groups. 
To scheduled reports go to configuration and scheduled reports. 
Once the script has completed there will be a result csv and if there are any non responding devices there will be a second csv.
The export result will look like the below. 
There are two options add machines using interactive script or add machines at scale. In this post we will be using the scripted method. 
Once the registration is completed, we can either copy the command or click download to get a copy of the PowerShell script. Below is how the script should look the only difference would be the Azure specific setting like resource group, tenantid…
Once the script has run and the connect command has completed it will request that we connect to the device login site 
