Search the Community

Introduction I've touched on this subject before where I used http triggers to add devices or users to an Azure AD group after Windows Autopilot was completed, however that solution did not check the compliance of the device prior to adding it to that Azure AD group, and you may have assigned profiles to that Azure AD group which depend on a compliant state. After Windows Autopilot is complete the compliance state of a device a can vary between any of the following states depending on various factors (usually time, and the number of compliance policies deployed and how they are configured). Compliant Not Compliant In grace period See ConfigMgr Not Evaluated The initial compliace state can eventually change to a state of compliant can take from a couple of minutes to some hours depending on what compliance policies you have configured. Refer to this docs post for more information about device compliance. Let's imagine you've configured a few compliance policies that check for the status of BitLocker Encryption of a device and Windows Defender anti malware definition updates. If the detected state of those polices don't match the configured policy then the device will be in a state of non compliance or even in something called in grace period. This post should help you solve the problem of adding devices (or users) to an Azure AD group after Windows Autopilot is complete, but only when they are in a state of Compliance that you want, in this case, Compliant. However it is complex, so before you start, please familiarize yourself with the following 2 posts, in fact I'd suggest you get the below working before proceeding as it will prepare you for this solution nicely. Adding devices to an Azure AD group after Windows Autopilot is complete - part 1 Adding devices to an Azure AD group after Windows Autopilot is complete - part 2 Understanding the solution So how does this all work ? The solution is actually made up of several scripts (and a trigger) listed below. CheckCompliance_CreateScheduledTask.ps1 The CheckCompliance_CreateScheduledTask.ps1 script will exit without doing anything if it detects that Autopilot was completed more than 48 hours ago. This script creates a scheduled task called CheckCompliance to run every 15 minutes. The scheduled task runs a CheckCompliance.vbs script which in turn runs a CheckCompliance.ps1 powershell script. Note: Both the CheckCompliance.vbs and CheckCompliance.ps1 scripts are embedded (base64 encoded) within the CheckCompliance_CreateScheduledTask.ps1 script. CheckCompliance.vbs This script is used to launch CheckCompliance.ps1 in hidden mode. CheckCompliance.ps1 This script does the actual call to the http trigger and provides the following data dynamically to the trigger: deviceName userName If the device is determined to be compliant it will then extract two more embedded scripts, then it runs AddDeviceToAzureAdGroup.vbs before finally deleting the scheduled task. Note: Both the AddDeviceToAzureAdGroup.vbs and AddDeviceToAzureAdGroup.ps1 scripts are embedded (base64 encoded) within the CheckCompliance.ps1 script. AddDeviceToAzureAdGroup.vbs This script simply runs the AddDeviceToAzureAdGroup.ps1 script in hidden mode. AddDeviceToAzureAdGroup.ps1 This script gathers the deviceId and userName and adds both items to an Azure AD Group. This uses the methodology of this blog post. httptrigger The http trigger itself uses the data delivered to it via the URL to determine compliance based on the data in managed Devices in Intune. How is compliance determined ? On a high level, compliance state is determined via queries in Microsoft Graph which you can test using Microsoft Graph Explorer. You can experiment yourself using a query such as the following. https://graph.microsoft.com/v1.0/users/USERID/managedDevices?$filter=deviceName eq 'ComputerName' Note: To manually test this you'll need to find valid UserID and ComputerName valuesfrom Intune and the results of this query would look something like below. Keep in mind that the UserID is reported as the id in Intune. The Scripted solution does the hard work for you, using Graph Explorer is where you start to test queries before creating the http trigger or back end scripts. Note that you'll need the following permissions granted in Graph Explorer to read this data (in addition to those listed in the previous blog post). Encoding/Decoding base64 scripts Included in the download are PowerShell scripts to encode/decode scripts. You can then edit them to your needs before re-encoding and adding the new base64 string to the appropriate variables. to set everything up please download the following scripts and extract to C:\Temp CheckCompliance.zip Make modifications as necessary to the CheckCompliance.ps1 and AddDeviceToAzureAdGroup.ps1 scripts before re-encoding. Save edited scripts to C:\Temp\CheckCompliance. To encode scripts simply run the relevant script shown below. There are two scripts, one for generating the base64 encoded scripts for the AddDeviceToAzureAdGroup and the other for the CheckCompliance scripts. The newly encoded scripts will be in the Encoded folder. Opening any of those 4 scripts will reveal the Base64 encoding data. Mark it all (Ctrl+a) and Copy it (Ctrl+c). Paste the Base 64 into the corresponding variable in the selected script. So to make changes to the AddDeviceToAzureAdGroup.ps1 script, simply edit the original Powershell script, then encode it, then copy the Base64 code into the corresponding section of the CheckCompliance.ps1 powershell script as shown below. Note that this is only an example, there are 4 embedded scripts in total, you'll get the hang of it soon enough. Decoding is the reverse process, and there are scripts available for you to do that also. Ok by now you should have all the above understood and working, time to deal with the solution. Step 1. Create a new http trigger I will assume you've already created a functionapp as per Step 4 of this blog post. If not, go ahead and create one and then return to this step. Next add the following code to your new http trigger. # Niall Brady 2021/02/15 # checks DEVICE for compliance # needs deviceName and userName to triangulate data # version 0.1 2021/02/15 Initial version, only queried against Azure AD devices # version 0.2 2021/02/17 queries against managedDevices to reveal compliance state more accurately using namespace System.Net # Input bindings are passed in via param block. param($Request, $TriggerMetadata) # Write to the Azure Functions log stream. Write-Host "PowerShell HTTP trigger function processed a request." # Interact with query parameters or the body of the request. $deviceName = $Request.Query.deviceName $userName = $Request.Query.userName if (-not $deviceName) { $deviceName = $Request.Body.deviceName } if (-not $userName) { $userName = $Request.Body.userName } # define the following variables $ApplicationID = "" # this is the id of the app you created in app registrations $TenantDomainName = "" # your tenant name $AccessSecret = "" # this is the secret of the app you create in app registrations # create the body $Body = @{ Grant_Type = "client_credentials" Scope = "https://graph.microsoft.com/.default" client_Id = $ApplicationID Client_Secret = $AccessSecret } # make initial connection to Graph $ConnectGraph = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantDomainName/oauth2/v2.0/token" -Method POST -Body $Body # get the token $token = $ConnectGraph.access_token # to improve logging... $triggerName = "Check compliance of a device" $a = Get-Date $body = " `n" $body = $body + "$a Starting the '$triggerName' function...`n" $body = $body + "$a Connected to tenant: $TenantDomainName.`n" # if $deviceName and $userName are provided do stuff.... if ($deviceName -and $userName) { $body = $body + "$a You supplied deviceName: '$deviceName'" + ".`n" $body = $body + "$a You supplied userName: '$userName'" + ".`n" # Start FinduserId $FinduserId = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/users/?`$filter=userPrincipalName eq '$UserName'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value if ($FinduserId.userPrincipalName){ $FinduserId = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/users/?`$filter=userPrincipalName eq '$UserName'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value | %{ $userId=$($_.Id) $body = $body + "$a Found the following userId: $userId"+ ".`n" } } else { Write-Host -ForegroundColor Green "$a UPN not found, FATAL." $body = $body + "$a UPN not found, FATAL." + ".`n" } # end $FinduserId # start FindmanagedDevice $FindmanagedDevice = Invoke-RestMethod -Method Get -uri "https://graph.microsoft.com/v1.0/users/$userId/managedDevices?`$filter=deviceName eq '$deviceName'" -Headers @{Authorization = "Bearer $token"} | Select-Object -ExpandProperty Value | %{ $complianceState=$($_.complianceState ) $body = $body + "$a Found the following complianceState: $complianceState"+ ".`n" } # end FindmanagedDevice # wrap things up... } $body = $body + "$a Exiting Azure function." # Associate values to output bindings by calling 'Push-OutputBinding'. Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{ StatusCode = [HttpStatusCode]::OK Body = $body }) Note. Make sure to add in the missing details (application name, tenant, secret) as per step 8 (no need for a groupID in this one). Step 2. Assign API permissions This httptrigger requires more permissions than previously, namely it must be able to read managedDevices. Below are the permissions I've configured. Step 3. Test the solution in Azure In Azure, paste the following into the Input field of the httptrigger, obviously replace the deviceName and userName fields with valid data from your enterprise. { "deviceName": "AP-791500385977", "userName": "niall@windowsnoob.com" } Click on Run when ready If everything went well the compliance state will be returned. The http trigger is working ! Step 4. Customise the scripts After you've downloaded the scripts it's time to customize them somewhat. In the CheckCompliance_CreateScheduledTask.ps1 change the company name and if you want more time to become compliant, increase (or decrease) the hours from the default value of 48 hours. In the CheckCompliance.ps1 script edit the following lines, make sure to paste in the httptrigger url from your environment in here. In the AddDeviceToAzureAdGroup.ps1 script edit the following variables, use the httptrigger to Add devices (and users) url which you created in this blog post Next, save the changes, re-encode the scripts and add the newly encoded base64 changes to the following scripts. Start with the CheckCompliance.ps1 script, paste in your encoded text here (in between the "") And do the same for the CheckCompliance_CreateScheduledTask Save the changes. Step 5. Deploy the solution In Intune, deploy the CheckCompliance_CreateScheduledTask.ps1 to one or more users as required. That script should contain all the other scripts above embedded if you followed the instructions correctly. Step 6. Verify solution Enroll a new Autopilot device and after logging in for the first time you should see a new Scheduled task appear shortly after you login. There is a corresponding log file for this scheduled task creation stored in the C:\Users\<USERNAME>\AppData\Local\Temp Note: In the screenshot above the time difference has been manually set to 1 hour, even though the install date is a month previous, this is just for testing purposes. This process also extracts the CheckCompliance scripts..into the users Temp folder And when 15 minutes has passed the CheckCompliance powershell script will be triggered by the scheduled task. and in this particular example we can see the computer is not compliant yet, therefore it won't kick off the other actions, which extracts scripts and then runs a script to join Azure AD based on a trigger as per this blog post the scheduled task will keep checking for compliance every 15 minutes (you can edit the script to change that) until the device is compliant, and once it is, the final payload will trigger. Below you can see the device is now reported as Compliant from Intune... and as a result it decodes the AddDeviceToAzureAdGroup scripts and then runs them, finally it deletes the scheduled task and the solution is nearly complete. Those scripts are extracted to the users Temp folder and when run create a AddDeviceToAzureAdGroup.log file. The remaining actions are up to you, you can deploy policy or whatever to that Azure AD group and your device/users will magically end up in this Group and receive policy after Windows Autopilot is complete as long as they have become compliant first. That's it ! job done ?

Does anyone know of a way to create a report that shows a list of Windows 10 Pro devices that are configured with BitLocker from Intune? Since they are using Pro Edition, Endpoint Protection Policies don't work so I am using the default Windows Device Restriction Policy that includes device encryption in the Azure AD Join process. The only type of reporting option I found was using Intune Data Warehouse in conjunction with PowerBI. So far, I set it to show "osCaption", "deviceName", and "encryptionState". The problem is that the data that comes out of the "encryptionState" is very confusing.

I am facing a very weird issue with SCCM CoManagement where Windows 10 machines registered to AzureAD in Hybrid Azure AD Join, are shown as Azure AD Joined. I will be focusing on one machine so we see the issue in depth. Configuration details SCCM Current Branch 1802 with all three hotfixes installed Windows 10 Enterprise 1803 with latest updates Co-Management Enabled for All Devices (no pilot group) No workloads have yet been migrated to Intune Group Policies for Automatic Enrollment to MDM and Automatic Registration with AzureAD enabled SCCM Client Cloud option for Automatic Registration enabled Intune set as Standalone Intune Enrollment set as MDM only (MAM disabled) ADFS Federated Domain 3.0 (2012R2) with AAD Connect Federation Facts SSO et. all are working as expected on the client Client detects client as Hybrid Azure AD Joined Intune detects client as Hybrid Azure AD Joined Issue SCCM detects client as Azure AD Joined I will now provide all relevant screenshots from Intune, SCCM and Client. SCCM As seen below, SCCM thinks the device is Azure AD Join and not Hybrid Azure AD Join. I also used the following SCCM query: select SMS_R_System.NetbiosName, SMS_Client_ComanagementState.Authority, SMS_Client_ComanagementState.AADDeviceID, SMS_Client_ComanagementState.ComgmtPolicyPresent, SMS_Client_ComanagementState.EnrollmentErrorDetail, SMS_Client_ComanagementState.EnrollmentFailed, SMS_Client_ComanagementState.EnrollmentStatusCode, SMS_Client_ComanagementState.HybridAADJoined, SMS_Client_ComanagementState.MDMEnrolled, SMS_Client_ComanagementState.MDMWorkloads, SMS_Client_ComanagementState.AADJoined from SMS_R_System inner join SMS_Client_ComanagementState on SMS_Client_ComanagementState.ResourceID = SMS_R_System.ResourceId where SMS_Client_ComanagementState.ComgmtPolicyPresent = 1 and SMS_Client_ComanagementState.MDMEnrolled = 1 And had the following results, same probem. Azure AD Joined = Yes, Hybrid Azure AD Joined = No AzureAD As seen on the Devices > Azure AD Devices, the machine is properly detected as Hybrid Azure AD Joined As seen below, DeviceTrustType = Domain Joined and DeviceTrustLevel = Managed should be correct (see here). Get-MsolDevice -Name hp-eb-g3 Enabled : True ObjectId : cxxxxxxxxxxxxxxxxxxxxxxxx0 DeviceId : 2xxxxxxxxxxxxxxxxxxxxxxxxxxxxx2 DisplayName : HP-EB-G3 DeviceObjectVersion : 2 DeviceOsType : Windows 10 Enterprise DeviceOsVersion : 10.0 (17134) DeviceTrustType : Domain Joined DeviceTrustLevel : Managed DevicePhysicalIds : {[USER-GID]:2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2, [GID]:g:6xxxxxxxxxxxxxxxx2, [USER-HWID]:2xxxxxxxxxxxxxxxxxxxxxxxxxxxxx2, [HWID]:h:6xxxxxxxxxxxxxxxxxx2} ApproximateLastLogonTimestamp : 27/07/2018 15:00:56 AlternativeSecurityIds : {X509:<SHA1-TP-PUBKEY>0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx} DirSyncEnabled : True LastDirSyncTime : 03/08/2018 02:31:16 RegisteredOwners : {} GraphDeviceObject : Microsoft.Azure.ActiveDirectory.GraphClient.Device Intune This is how the device shows up in Intune Client DeviceManagement Log event 75 properly happened Client properly seeing management from Intune dsregcmd properly recognizes machine as AAD and MDM enrolled and AD Domain Joined dsregcmd /status +----------------------------------------------------------------------+ | Device State | +----------------------------------------------------------------------+ AzureAdJoined : YES EnterpriseJoined : NO DeviceId : 2xxxxxxxxxxxxxxxxxxxxxxxxx2 Thumbprint : 0xxxxxxxxxxxxxxxxxxxxxxA KeyContainerId : cxxxxxxxxxxxxxxxxxxxxxx7 KeyProvider : Microsoft Platform Crypto Provider TpmProtected : YES KeySignTest: : PASSED Idp : login.windows.net TenantId : 9xxxxxxxxxxxxxxxxxxx2 TenantName : Axxxxxxxxxxxxxs AuthCodeUrl : https://login.microsoftonline.com/9xxxxxxxxxxxxxxxxxxxx2/oauth2/authorize AccessTokenUrl : https://login.microsoftonline.com/9xxxxxxxxxxxxxxxxxxxxxxxxx2/oauth2/token MdmUrl : https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc MdmTouUrl : https://portal.manage.microsoft.com/TermsofUse.aspx MdmComplianceUrl : https://portal.manage.microsoft.com/?portalAction=Compliance SettingsUrl : JoinSrvVersion : 1.0 JoinSrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/device/ JoinSrvId : urn:ms-drs:enterpriseregistration.windows.net KeySrvVersion : 1.0 KeySrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/key/ KeySrvId : urn:ms-drs:enterpriseregistration.windows.net WebAuthNSrvVersion : 1.0 WebAuthNSrvUrl : https://enterpriseregistration.windows.net/webauthn/9xxxxxxxxxxxxxxxxxxxxxxxxxxxx2/ WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net DeviceManagementSrvVersion : 1.0 DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/9xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2/ DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net DomainJoined : YES DomainName : XXXXXXXXXX +----------------------------------------------------------------------+ | User State | +----------------------------------------------------------------------+ NgcSet : NO WorkplaceJoined : NO WamDefaultSet : YES WamDefaultAuthority : organizations WamDefaultId : https://login.microsoft.com WamDefaultGUID : {Bxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0} (AzureAd) AzureAdPrt : YES AzureAdPrtAuthority : https://login.microsoftonline.com/9xxxxxxxxxxxxxxxxxxxxxxxxxx2 EnterprisePrt : NO EnterprisePrtAuthority : +----------------------------------------------------------------------+ | Ngc Prerequisite Check | +----------------------------------------------------------------------+ IsUserAzureAD : YES PolicyEnabled : NO PostLogonEnabled : YES DeviceEligible : YES SessionIsNotRemote : NO CertEnrollment : none AadRecoveryNeeded : NO PreReqResult : WillNotProvision Can anyone having a similar configuration crosscheck and let me know what difference there is? References: https://www.imab.dk/flipping-the-switch-how-to-enable-co-management-in-configuration-manager-current-branch/ https://allthingscloud.blog/automatically-mdm-enroll-windows-10-device-using-group-policy/ -- Alex