NinjaCat's ConfigMgr/Intune/EMS Adventure

Assigned Access with Intune and AssignedAccess CSP – Part II

Matt Hinson (MSFT) — Thu, 23 Aug 2018 05:53:17 GMT

Hello all, Back with part two of our blog dealing with Assigned Access profiles leveraging the AssignedAccess CSP. If you haven't read Part I of this blog, you can read it here: https://blogs.technet.microsoft.com/matt_hinsons_manageability_blog/2018/08/23/assigned-access-with-intune-and-assignedaccess-csp-part-i/

Summary

In the previous blog, we discussed Assigned Access, the use cases for Assigned Access, discussed the AssignedAccess CSP documentation, and walked through how to build the XML that we need for our Assigned Access policy in Intune. In this part of the blog, we'll discuss Windows 10 Autopilot settings, configuring and deploying the policy in Intune, and spend some time validating our results on the device. Ok, a little bit of additional background for our example. In our example, recall we are configuring a policy for the use case of an administrator who wants to restrict activity on devices for a subset of multiple users across different devices. In this scenario, the administrator only wants to give the users access to the following applications:

Microsoft Edge (UWP app)
Calculator (UWP app)
OneNote (UWP app)
Notepad (desktop app)

If you've already looked at the provided sample XML from part one of this blog, you've seen the XML has already been configured for the scenario mentioned above. If you haven't, challenge yourself by building the XML on your own by following along in part one of this blog.

Windows 10 Autopilot and Devices

Recall we discussed Windows 10 Autopilot briefly. The one caveat about your Windows 10 Autopilot profile is that the user account type setting must be set to Standard. There are a couple of reasons for this:

Per our AssignedAccess CSP documentation, it's not supported and we are warned that we may experience inconsistent results if an Assigned Access profile is deployed to an administrator account
Per our AssignedAccess CSP documentation, several additional settings are automatically configured when the Assigned Access profile is applied. Namely, the Start menu Show All Apps list button is hidden. If an Assigned Access profile is applied to an administrator account, some settings, namely this one, will not apply properly and a user will be able to access all applications from the Start menu. This doesn't mean the apps will run, they won't based on the Assigned Access policy. However, when a user clicks on an app icon, they'll get a pop-up saying the app is not allowed. This is not an ideal user experience and may prompt a helpdesk call from the user.

As mentioned in the Part I, ensure you are leveraging an Enrollment Status Page to keep the device in OOBE until the Assigned Access profile is applied. In this manner, when the user logs in for the first time, the Assigned Access profile will be applied and configured from start. Recall we also discussed leveraging physical devices. The reason for this recommendation is because if you use a VM, at least a Hyper-V VM, when the Windows 10 Autopilot configures the user account as a standard user account, that account will not have rights to log on remotely, you will effectively be locked out of the VM, and the configuration will not complete. You can use a Hyper-V VM for testing, but the Windows 10 Autopilot profile must have the user account type set to administrator. Your policy will apply in this manner, but recall it will not set all the settings as mentioned earlier. It is recommended to leverage physical devices for testing so you get the full effect of your Assigned Access policy and you can evaluate the policy as an end user to understand if you need to tweak your policy at all.

Create and Deploy the Assigned Access Policy in Intune Portal

Remember our XML from part I? Go ahead and get that ready.

Open up a browser and navigate to your Intune portal
In the Intune blade, click Device Configuration
In the Device Configuration blade, click Profiles
In the Device Configuration - Profiles blade, click the Create Profile button
On the Create Profile blade, in the Name field, name the profile accordingly. In the Platform drop-down, choose Windows 10 and later. In the Profile type drop-down, choose Custom
The Custom OMA-URI Settings blade will appear. Click the Add button
On the Add Row blade, in the Name field, name the settings accordingly.
In the OMA-URI path, copy and paste ./Device/Vendor/MSFT/AssignedAccess/Configuration
In the Data type drop-down, choose String
In the Value text box, copy and paste the XML you created in part I
Click OK to close the Add Row blade
Click OK to close the Custom OMA-URI Settings blade and click Create to create your policy
Once created, click the policy. On the Policy blade, click Assignments
On the Assignments blade, in the Assigned to drop-down, select Selected Groups and then click Select groups to include
On the Azure AD Groups blade, choose your Windows 10 Autopilot devices group. NOTE: This would have been completed already as part of your pre-requisites in Part I of this blog
On the Assignments blade, click Save

Provision a Windows 10 Autopilot Device and Validate the Result

Boot a test device into OOBE and click through the screens
When you reach the Add an Account screen, use your work account to Azure AD Join the device and enroll the device in Intune
At this point, you'll see the Enrollment Status Page
Wait a bit for the process to complete
Once complete, the user should be auto-logged in and you should see your Assigned Access profile has been applied successfully. It should look a little something like the screens below

As you can see, the Assigned Access profile was successfully applied and we only see the 4 Start menu icons we configured for our allowed apps. In this screen, notice I do not have the Start menu Show All Apps button. I all I have is the Pinned Tiles button Lastly, a user can still swipe in from the right and attempt to access the Settings app, but guess what? Yep, that's right, it's blocked! Once you get to this point, kick the tires a little bit and see if you can beat the Assigned Access profile!

Troubleshooting

If for some reason your AssignedAccess CSP policy isn't working as expected, check the Device status for the policy in the Intune portal.

Open up a browser and navigate to your Intune portal
In the Intune blade, click Device Configuration
In the Device Configuration blade, click Profiles
Click your AppLocker Policy. On the Policy blade, click Device status
On the Device status blade, review the results. If you see an error, click the entry to drill down. If the error comes back as Remediation Failed, you have a malformed XML string value. A good way to check to see if your XML is malformed or not, open up the XML file in Internet Explorer. If you don't see the familiar XML formatting, but rather a blank page, you have a malformed XML. Go back and review the XML value you copied into the policy. Review the sections in the blog series that discusses the XML value

Wrap Up

Alright, that's it! I hope you had as much fun as I did! Always cool to see the power of Intune at work. The unfortunate aspect of this blog is what I mentioned in part I, as Windows 10 1803 becomes standard across organizations and Intune's kiosk mode evolves into a generally available feature, all of our hard work here is rendered moot. But hey, it sure was cool tinkering and engineering a stop-gap while we wait for that evolution to occur. Until next time!

Assigned Access with Intune and AssignedAccess CSP - Part I

Matt Hinson (MSFT) — Thu, 23 Aug 2018 01:47:35 GMT

Hello all, Back again, much faster this time around! This two part blog picks up or adds to my last blog regarding creating AppLocker policies with AppLocker CSP and Intune. If you missed that post, check it out here: https://blogs.technet.microsoft.com/matt_hinsons_manageability_blog/2018/08/21/blocking-apps-with-intune-and-applocker-csp/

Summary

In my previous blog post, I mentioned my thoughts on the whitelisting approach to blocking application activity on devices. I mentioned that when an administrator desires to take a whitelisting approach, they want to lock down the application activity on their devices. I also mentioned that leveraging a whitelist approach will, more than likely, result in a ton of Allow rules in your AppLocker policy. And finally, I mentioned that for those who want to take a whitelisting approach, why not consider leveraging an Assigned Access profile? This two part blog is going to explain what Assigned Access is, the use cases for it, and how to create an Assigned Access profile in Intune. In this part, we'll discuss the background of our strategy, examine the docs, and build our XML. In part II of the blog, we'll configure our policy in Intune and validate our results. NOTE: While you can certainly deploy an Assigned Access profile to an already provisioned device that is enrolled in Intune (for the policy to apply, the user must log out and back into the device), this blog will assume you are provisioning devices with Windows 10 Autopilot. We will not cover configuring Windows 10 Autopilot in this blog. If you have not already setup Windows 10 Autopilot, below is a bulleted list (in order) to get you started on configuring Windows 10 Autopilot before jumping in on this blog:

Gather device hardware IDs - https://blogs.technet.microsoft.com/mniehaus/2017/12/12/gathering-windows-autopilot-hardware-details-from-existing-machines/
Prepare the Intune tenant for Windows 10 Autopilot - https://docs.microsoft.com/en-us/intune/enrollment-autopilot
Configure an Enrollment Status Page in Intune - https://github.com/MicrosoftDocs/IntuneDocs/blob/master/intune/windows-enrollment-status.md

Pre-Requisites

Windows 10 Autopilot is configured in your Intune tenant
Devices that are at least Windows 10 1709
Devices that are physical in nature. NOTE: It is possible to test with a VM, but works best with a physical device. More on this later
Azure AD group that contains users who will log into devices that will leverage the Assigned Access policy

What is Assigned Access and Why Use It?

With Assigned Access, an administrator can limit an existing user account to use only one or multiple installed Windows apps that they choose. This can be useful to set up single-function devices, such as restaurant menus or displays at trade shows (kiosks). Or, it can be useful for provisioning highly restricted devices. Use cases for this would include provisioning of contractor devices, multi-user devices, training room devices, or for admins who want to restrict their user base to certain activity. Our example will follow that of an admin who wants to restrict a subset of different users on their devices. Now, if you are aware of the feature set in Intune, you may be aware that I'm already describing a feature that exists in Intune. And you would be correct, to an extent. At the time of writing this blog, Intune currently has a feature called Kiosk Mode. However, it is in preview. This means you can use the feature, but should not use the feature for wholesale use as results can be inconsistent since the feature is not generally available yet. If you have already tested this feature thoroughly, you know this to be the case. I have tested the feature and it's great! I can't wait to see it fully ready and how it will evolve over time. But it's not ready for primetime just yet. Unfortunately, kiosk mode does not work with an Enrollment Status Page, which is also in preview. The importance of the Enrollment Status Page is that this page keeps the device in OOBE so all the Intune policies and applications are applied/deployed to the device so that when the user logs on, it's ready to go and there is no need to wait for policy to come down for the device. Specific to Assigned Access policy, we want the policy applied from the moment the user is logged in rather than waiting on the policy to come down, be applied, and requiring the user to log out and back in for the Assigned Access profile to take effect. Also, kiosk mode (Preview) is also limited to Windows 10 1803. If your devices are not Windows 10 1803, the policy will not be applicable and Intune will let you know that in the policy configuration status node. Lastly, I'll be the first to admit that everything I just said and everything you read below becomes a moot point over time as Windows 10 1803 becomes standard across organizations and kiosk mode in Intune becomes a full fledged feature in Intune. In the meantime, all is not lost! We can leverage the AssignedAccess CSP for devices that are at least Windows 10 1709 to deploy an Assigned Access profile. Buckle up, this ride is bumpy and a little complex, but we'll get through it!

The Plan

I love it when a plan comes together! Bonus points if you know where that saying comes from. As always, the legwork has been completed already to provide this example so you don't have to struggle though it. For those of you who read my blogs religiously, you know I'm a documentation fiend. So our first item is to consult the documentation on the AssignedAccess CSP. https://docs.microsoft.com/en-us/windows/client-management/mdm/assignedaccess-csp Let's examine the docs: First thing we want to understand is our OMA-URI path. We see from the documentation that the OMA-URI path is: ./Device/Vendor/MSFT/AssignedAccess/Configuration We also see from the documentation that Configuration setting was added in Windows 10 1709 devices and is used to configure the settings of our Assigned Access policy. Reading the documentation further, we see the policy setting requires an XML and it must be a string value. And that's about it for the documentation. It's a lot of information, but there are still questions on how we need to approach this. Continuing down in the documentation, there is an AssignedAccess XML example that is provided. However, there isn't much context around what any of contents of the XML means. We can find that information in the link below. You should review this in order to understand the XML contents better: https://docs.microsoft.com/en-us/windows/configuration/lock-down-windows-10-to-specific-apps From reviewing the example XML tags, it gives us our outline on how we need to build this policy.

tag - We need to build our list of apps we want to allow in the XML
tag - We need to provide a Start Menu layout in the XML
tag - We need to configure an account config in the XML

I have provided a sample XML file as part of this blog. It will be much easier on you to use the provided sample. Before we move on any further, I want to call out a couple pitfalls in the documentation XML example. Just as I mentioned in the AppLocker blog, a subset of the example XML is what is needed as part of the string value for our policy and that was not called in the documentation. should not be included in the string value for your policy. Everything else in the XML is fine. If you include this line in your XML, you'll get a Remediation Failed error. The next pitfall is the MultiAppKioskUser. The bolded text in the previous sentence is merely a placeholder. This is not called out in the docs. So if you don't update this configuration, thinking it is a universal variable of sorts, and you leave this as is in your string XML, you'll get a Remediation Failed error. I'm probably being a little critical of our docs here, but I can see where this could cause confusion and frustrate someone to no end.

Building the XML

Earlier we mentioned by reviewing the example XML, we see the steps we need to do to build our XML file. The first step is building our AllowedApps list. Let's review an section example: Apologies for the formatting, but for some reason, I can't indent the text to look like typical a XML tree. <App AppUserModelId="Microsoft.ZuneMusic_8wekyb3d8bbwe!Microsoft.ZuneMusic" /> <App DesktopAppPath="%windir%\system32\mspaint.exe" /> <App DesktopAppPath="C:\Windows\System32\notepad.exe" /> Notice the red text above. The first line is an example tag for a UWP app that we want to allow leveraging the tag. The bottom two lines are an example of EXE apps that we want to allow leveraging the tag. Looking at the values of these tags, the tag is pretty easy to discern. The examples show you can use a literal path or system variables as part of the value. Leveraging a test device, that is of the same version you plan on deploying the policy, simply open up File Explorer and find the paths of the EXE you want to allow. Copy and paste the paths into the "" for the tag. Then copy and paste the entire line to the next line in the XML. Rinse and repeat until you have added all the EXE files you want to allow. Now the tag is a bit more challenging just because of the lovely ID format that UWP apps use. In order to get the AppIDs, run the following Powershell script on a test device that is of the same version you plan on deploying the policy: $installedapps = get-AppxPackage $aumidList = @() foreach ($app in $installedapps) { foreach ($id in (Get-AppxPackageManifest $app).package.applications.application.id) { $aumidList += $app.packagefamilyname + "!" + $id } } $aumidList | Out-File -FilePath C:\AUMIDList.txt Again, apologies for the formatting. But the Powershell script above will spit out a text file with all the IDs for the UWP apps. Open the text file and review the IDs of the apps you wish to allow. Similar to the way you configured your tags, simply copy and paste the App ID into the "" for the tag. Then copy and paste the entire line to the next line in the XML. Rinse and repeat untl you have added all the modern apps you want to allow.

The section is much easier to obtain. On a test device that is of the same version of Windows 10 that you wish to deploy the policy to, configure the Start menu tiles to your liking. For Assigned Access profiles, you'll only want to include the tiles that correspond to your Allowed apps in your policy. Once you are happy with the Start menu, open up Powershell and run the following Powershell script: Export-StartLayout -Path C:\Start.xml Once you have the Start.xml file, open the Start.xml in Notepad and copy the entire contents of the Start.xml into the policy XML under the in between the tag. If this is confusing, review the example in the documentation to understand where you should paste the Start.XML contents.

The last item we need to configure is the tag. At the linked doc within the AssignedAccess CSP docs: https://docs.microsoft.com/en-us/windows/configuration/lock-down-windows-10-to-specific-apps We can see the different account types we can configure here. We can configure local users, domain users, Azure AD users. We can also configure user groups such as local groups, AD groups, and AzureAD groups. In our example, configuring an Azure AD group is ideal as we want the policy to apply to multiple users. In order to leverage an AzureAD group, we need to get the group ID of the Azure AD group that contains the users you wish this policy to apply to.

Open a browser and go to portal.azure.com
Open the Azure Active Directory blade
Open the Groups blade
On the Groups blade, search for the group that contains the group of users you wish the Assigned Access policy to. Click on the Group
In the left pane, click Properties
Copy the Object ID of the Azure AD group and notate this

Now that we have our Azure AD group ID, let's build the tag, which for us, is actually the tag since we are leveraging an Azure AD group <UserGroup Type="AzureActiveDirectoryGroup" Name="79d90a36-9060-4bc3-a397-a9103a98526c" /> Within the tag, copy the Azure AD group Object ID you notated earlier between the "" of the Name value. See above for an example. Once you have completed this section, you are done! Save your XML. We will use this XML in the next blog to configure our Assigned Access policy in Intune.

Wrap Up

You can see why I split this up into a two part blog! I told you it'd be bumpy, but we got through it. The hard part is over. Nice job! In the next part, we'll configure the Intune policy and deploy it out and we'll validate the results of our Assigned Access policy. Here is the link to download the sample XML for our example: https://1drv.ms/t/s!Avb5Zr26pC54gt5AaxHwwsSvZWqHUw Ready to keep going? Part II is below. https://blogs.technet.microsoft.com/matt_hinsons_manageability_blog/2018/08/23/assigned-access-with-intune-and-assignedaccess-csp-part-ii/ And now, the obligatory disclaimer for the provided example at the link above: © 2018 Microsoft Corporation. All rights reserved. Sample scripts or files in this blog are not supported under any Microsoft standard support program or service. The sample scripts or files are provided AS IS without warranty of any kind. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Blocking apps with Intune and AppLocker CSP

Matt Hinson (MSFT) — Tue, 21 Aug 2018 15:14:03 GMT

Hello everyone, Back with another experience to share with you all. This past week, a customer asked if it were possible to create policy to block certain applications from being able to be opened up on Windows 10 devices enrolled in Intune. At the time of writing this blog, such functionality is not available natively within Intune. As in, AppLocker is not an option for a Windows 10 profile type within the Intune portal. However, anytime there is an ask regarding policy that is not native to Intune, we need look no further than searching our CSP library to see if we have the ability to configure policy via OMA-URI. Sure enough, after a quick search, we see we have an AppLocker CSP. So naturally, it's time to review the documentation on the AppLocker CSP. https://docs.microsoft.com/en-us/windows/client-management/mdm/applocker-csp We see from the documentation that our OMA-URI path for what we want to achieve looks like this: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/Grouping/EXE/Policy Notice the word Grouping is bolded above. This is bolded because this is a grouping GUID that can literally be anything you want it to be. For my example, I'm going to use BlockedApps01 as my grouping GUID. So my OMA-URI path is going to look like this: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/BlockedApps01/EXE/Policy. This will be important for later when we create our policy in Intune. Also note in the documentation, we have EXE, MSI, Script, StoreApps, DLL, and CodeIntegrity. Each of these represent the different AppLocker rules you can create as part of an AppLocker policy. For *.exe files, you'd use EXE as part of your OMA-URI path. For any *.appx or modern apps, you would use StoreApps as part of your OMA-URI path. Finally, we have Policy. This is where the actual XML value needs to be specified. And that value will be a string value in the policy. More on this later as we walk through creating the policy in Intune in a bit.

Creating the AppLocker Policy

Now it's time to take a look at creating the AppLocker policy on a test device so we can get our XML for the Policy string value as part of our policy. Now, there are a couple different approaches to creating AppLocker policies. You have whitelisting and blacklisting. Whitelisting is blocking all apps except for the ones you explicitly allow in your AppLocker policy. Blacklisting is allowing all apps and blocking only the apps you explicitly deny in your AppLocker policy. As a result, whitelisting is the far more restrictive method. However, depending on your requirements and how restrictive the policy, you may end up creating a lot more whitelisting rules than blacklisting rules. This is a personal opinion of mine, but leveraging whitelisting implies that an administrator wants to lock down a device pretty tightly and only allow specific application activity. So rather than annoy your users with pop-ups saying they can't access an application due to policy, why not use an Assigned Access profile? I've worked with customers in the past where we did this via Intune and used Powershell scripts to push out an Assigned Access profile to achieve a similar result as whitelisting. You can also achieve such by leveraging the AssignedAccess CSP on Windows 10 1709 and later devices. Kiosk mode, once it's out of preview would also be a solution, but I digress. For this example, I'm going to be using the blacklisting approach and picking something simple like Notepad to block. Are you ready? Let's get started!

On a Windows 10 test device that has all the desired apps you wish to create an AppLocker policy for, open the local group policy editor. You can do this by clicking Start and typing in "edit group policy" and hitting enter. Once the Local Group Policy Editor opens up, navigate to Computer Configuration > Security Settings > Application Control Policies > AppLocker. Within the AppLocker node, you'll see the different types of rules you can create. Recall we briefly discussed this earlier looking at the AppLocker CSP OMA-URI path.
Since we are going to be using Notepad for our example, we are going to create a Executable Rule. If you wanted to block the built-in Calendar modern app, you would create a Packaged app Rule. Right-click on Executable Rules and select Create New Rule.
In the Create Executable Rules wizard, on the Before You Begin screen, click Next
On the Permissions screen, click the Deny radio button and click Next
On the Conditions screen, ensure the Publisher radio button is selected and click Next
On the Publisher screen, in the Reference file: field, click the Browse button. File Explorer will open. Browse to C:\Windows\System32\ and double-click on notepad.exe. The details of the file will be filled in for you. Click Next
On the Exceptions screen, click Create
You'll get a prompt to create default rules, click Yes.
In the left pane, click on the AppLocker node. Back in the right-pane, click the Configure rule enforcement link
The AppLocker Properties window will appear. Under Executable rules: check the Configured checkbox and select Enforce rules from the dropdown menu. Click OK to close the window
In the left pane, right-click on the AppLocker node and select Export Policy
File Explorer will open. Save the XML to a location on the test device and copy it to your primary machine

Working with the XML

So we've got our XML and earlier we mentioned we need the XML as it will be the Policy string value for our OMA-URI. If only it were that easy. What our docs don't tell you is if you were to copy and paste all of the XML file contents to the Policy string value for our OMA-URI and deploy it, it will fail. What we have to do is copy only a subset of the XML and use that as our Policy string value. Not sure why, but there is zero mention of this on the AppLocker CSP docs page. It took some trial and error and discussing with some colleagues to understand why this was failing for me at first because I was following the docs. Hence the reason for this blog, so you don't waste 8 hours wondering what the heck is going on. Let's take a look at the XML and I'll explain what subset is required for the policy to work properly. Everything in the red text above represents what needs to be used for our Policy string value for our OMA-URI. The trick here is to ensure you are only copying the RuleCollection tag that shows as "Enabled" (bolded at the top of the XML) down to the closing RuleCollection tag (bolded at the bottom of the XML) just before the "NotConfigured" RuleCollection tags. Everything else should be omitted. Ok, we've got what we need, now time to go to the Intune portal and let's create our policy.

Create and Deploy the AppLocker Policy in Intune Portal

Open up a browser and navigate to your Intune portal
In the Intune blade, click Device Configuration
In the Device Configuration blade, click Profiles
In the Device Configuration - Profiles blade, click the Create Profile button
On the Create Profile blade, in the Name field, name the profile accordingly. In the Platform drop-down, choose Windows 10 and later. In the Profile type drop-down, choose Custom
The Custom OMA-URI Settings blade will appear. Click the Add button
On the Add Row blade, in the Name field, name the settings accordingly.
In the OMA-URI path, we will use what we mentioned earlier in the blog. Copy and paste ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/BlockedApps01/EXE/Policy
In the Data type drop-down, choose String
In the Value text box, copy and paste the XML subset we discussed above (everything in the red text above)
Click OK to close the Add Row blade
Click OK to close the Custom OMA-URI Settings blade and click Create to create your policy
Once created, click the policy. On the Policy blade, click Assignments
On the Assignments blade, in the Assigned to drop-down, select Selected Groups and then click Select groups to include
On the Azure AD Groups blade, choose the groups you want the policy to be applied to and click Select
On the Assignments blade, click Save

Alright, you've now deployed your AppLocker policy to your desired devices or users. Now it's time to see if it worked.

Validating the Result

Ok, you've worked hard thus far. Go grab a cup of joe and doughnut, you deserve it! No seriously, this step is crucial to give the policy time to get to your device. By the time you are done, your policy should be applied to your test device. Of course, you can expedite this process by syncing the device with Intune.

On your test device, click Start and type in notepad
Click on notepad to open it
You get the wonderful screen that was the picture for this blog. On legacy versions of Windows 10, such as 1607, you will not get a pop-up stating the application cannot be run. Instead, nothing will happen. If you were to then navigate to the actual file location and attempt to run the blocked application, then you will get a red X pop-up stating the application cannot run

Troubleshooting

If for some reason your AppLocker policy isn't working as expected, check the Device status for the policy in the Intune portal.

Open up a browser and navigate to your Intune portal
In the Intune blade, click Device Configuration
In the Device Configuration blade, click Profiles
Click your AppLocker Policy. On the Policy blade, click Device status
On the Device status blade, review the results. If you see an error, click the entry to drill down. If the error comes back as Remediation Failed, you have a malformed XML string value. A good way to check to see if your XML is malformed or not, open up the XML file in Internet Explorer. If you don't see the familiar XML formatting, but rather a blank page, you have a malformed XML. Go back and review the XML value you copied into the policy. Review the section above that discusses working with the XML file to find the issue with your XML.If you see success, but the specific applications are still running, review your AppLocker policy default rules to understand if you are allowing something in your policy that you shouldn't be.

Wrap Up

Alright, that's it! I hope you got something from this blog. A quick note on whitelisting as I don't want to leave that approach out entirely. With a whitelist approach, the default rules that are mentioned earlier in this blog come into play. For example, with a whitelist approach, you would only retain the Allow > Everyone > (Default Rule) All files located in the Windows folder rule. This now means that the user will not be able to run any applications that does not reside within the Windows folder. Yep, that's right, they won't be able to run Notepad because it resides in the System32 subfolder. It also means that the majority of the modern apps will also be blocked; such as Paint3D and the XBOX app. Even the Microsoft Store app will be blocked. Keep this in mind. While a whitelist approach is more restrictive, it does mean you may end up creating a lot more rules than with a blacklist approach. Again, in lieu of a whitelist, consider using an Assign Access profile. I guess I have the topic for my next blog! Until next time, happy AppLockering!

Configuration Manager - Setting up Cloud Services using Wildcard Certificates

Matt Toto - MSFT — Thu, 28 Jun 2018 19:34:56 GMT

Hello all, I wanted to take a second to introduce a new contributor to the blog, Matt Toto. Matt and I have known each other for about 5 years and have even teamed up on some customer engagements recently. I asked Matt if he'd like to bring his expertise to this blog and he graciously agreed. With that, take it away Matt.... =================================================================================================================== Hi Everyone! This is Matt Toto, I'm a ConfigMgr PFE focused on Cloud Services. In this article I'll be sharing how to use a wildcard certificate for setting up both the Cloud Management Gateway and Cloud Distribution Point. Support for this capability was added to Configuration Manager in 1802. Using a Wildcard Certificate to Create Cloud Service is Configuration Manager (CMG and CDP) has a lot of benefits. It reduces cost and maintenance of PKI. This single wildcard cert can be used as a Management Certificate, if using Classic Deployment Model. As well as be used to create potentially unlimited CMG's and CDP's. The process is quite simple. Let's get started! Step one is to obtain a wildcard cert for your domain. For example, *.contoso.com, using either Internal PKI or Publicly Provided. In my lab I use a public cert, provided by DigiCert, for an ARM CMG, this example is based off that configuration. Next you'll need to create a Cloud Management Gateway in Configuration Manager. On the General tab, sign in as an administrator account to provide Configuration Manager with access to your subscription info. On the Settings Page of the Wizard specify your wildcard certificate, enter the password. You will receive the following prompt, informing you about the Common Name (CNAME) of the certificate having a wildcard. Its ok, we'll fix that in a bit. For now, just click OK, ok? Initially your screen will look something similar to this. Note that its telling you the name cannot contain special characters. Which, for the moment, it does. This is where you come in! Notice the Service FQDN box? Yes, it does look unhappy with that red SPLAT. But, it also looks like you can type in that box, right? Normally you cannot enter text here because it is auto-populated, based on the CNAME field in the certificate. In this case, because it’s a wildcard, you actually NEED to type a unique name here. Go ahead, type something unique. All you have to do is come up with a unique name, enter it in the box, then click out of the box. Once you do that the Service Name box will display the name provided and you can continue with the setup. Like so… After finishing out the Wizard, the service will be provisioned with that as its 'Service Name' and the Cloud Service Name will be appended with .cloudapp.net Now that the service is provisioned, you'll need to update DNS. Add a CNAME that maps the Service Name (which is the name that your SCCM Client will try to resolve) to the Cloud Service Name which will be, in this example, UniqueName.cloudapp.net. That's it! Support for the wildcard certificate is a game changer for setting up the Cloud Management Gateway and Cloud Distribution Point in Azure!

Intune enrollment for iOS supervised mode with Apple Configurator

Matt Hinson (MSFT) — Tue, 13 Feb 2018 17:54:13 GMT

Hello all, Back again with another blog post. This time, we'll be diving into Intune enrollment iOS supervised mode via Apple Configurator. Admittedly, this is something I'd heard about sparingly, but never really tinkered with until a customer of mine came to me with a requirement that they needed to be able to disable iMessage on specific iOS devices in their Intune tenant. I was aware of supervised mode and knew it was attainable with enrollment in Apple's DEP program. However, I wasn't aware that supervised mode is also attainable leveraging Apple Configurator and Setup Assistant. So what is iOS supervised mode? iOS supervised mode is an enrollment state of an iOS device that allows an administrator more control over a device than in traditional BYOD scenarios. The settings that are opened up to an administrator for control in supervised mode are listed in the first link below, one of which being iMessage control. So, our focus for to today is step-by-step instructions on how I did a proof of concept in my Intune tenant before assisting my customer with the implementation. I do have screenshots for the steps below. But for now, I will not include them as to avoid making the blog so long I'd need to break it up into parts. However, If enough people comment they would like screens, I will include them. So where do we begin? Like any good Microsoft employee, when my customer asked if this were possible, I reviewed our documentation on the topic. iOS Device Restrictions Enroll iOS devices with Apple Configurator And per usual, I had more questions after reviewing the docs. As such is the purpose of this blog. To lay it all out to make it easier on you if you so decide to implement a similar scenario. First things first, we have some pre-requisites. Ensure you meet the pre-requisites before proceeding any further. Pre-Reqs for Apple Configurator Enrollment Step 1: Create the Apple Configurator Profile in Intune tenant

Open a web browser and go to http://portal.azure.com
In the left pane, select More Services and type in Intune. Click Intune to open the Microsoft Intune management blade
Within the Intune blade, select Device enrollment
On the Device enrollment blade, select Apple enrollment
In the Manage Apple Configurator Enrollment Settings section, select AC Profiles
On the Apple Configurator Enrollment Profiles blade, click Create to create a profile
On the Create Enrollment Profile blade, type in a name for the profile in the Name field. In the User Affinity dropdown, ensure Enroll with user affinity is selected and click Create
Close all the blades to get back to the Intune management blade

Step 2: Create an Intune group to populate devices

In the Intune management blade, in the left pane, click on Groups
In the Groups blade, in the middle pane, click New group
On the Group blade, set the Group Type drop-down to Security. Type in a name for the group in the Group name field. For example, iOS Supervised Devices. Set the Membership type drop-down to Dynamic Device
Click the Add dynamic query box
On the Dynamic membership rules blade, set the first dropdown to enrollmentProfile. Change the second dropdown to Equals. In the third field, type in the name of the enrollment profile you created in step 7 of the previous section and click Add query
Back on the Group blade, click Create to create the group

Step 3: Upload a CSV that contains the serial numbers and details of devices to be enrolled with Apple Configurator and assign the AC profile to the devices

Open Excel and created a 2-columned CSV file that contains the serial number of the device in the first column and details in the second column. For example, in the first column, type in 123456789. In the second column type in Matt's iPad.
Save the file as a CSV file
Within the Intune blade, select Device enrollment
On the Device enrollment blade, select Apple enrollment
In the Manage Apple Configurator Enrollment Settings section, select Apple Configurator Devices
On the Apple Configurator Devices blade, click Add
On the Add Devices blade, in the Select Profile drop-down, select the AC profile
Within the Specify the path to the list you want to import, click the blue folder icon and browse to the CSV you created earlier and click Open
Click Add to import the device list
Close the Add Devices blade. Back on the Apple Configurator Devices blade, you should see the devices from the device list you imported
Click on each device and click Assign Profile
On the Assign Profile blade, select the AC profile from the drop-down and click Assign
Repeat steps 11-12 until all devices are assigned the AC profile
Close all the blades to return to the Intune management blade

Step 4: Export the AC Profile to obtain MDM URL for Intune tenant for Apple Configurator

Within the Intune management blade, select Device enrollment
On the Device enrollment blade, select Apple enrollment
In the Manage Apple Configurator Enrollment Settings section, select AC Profiles
Select the AC profile you created earlier in Step 1
In the AC profile blade, click Export Profile
In the Export Profile blade, copy the value in the Profile URL field to notepad and save as you will need it later
Close all blades to return to the Intune management blade

Step 5: Create Apple Configurator Profile to manage settings

On a supported Mac device, preferably running High Sierra, download and install Apple Configurator 2 from the app store
Open Apple Configurator 2
In top left corner is the Apple Configurator menu, click File and select New Profile. NOTE: A window called All Devices may be in the forefront, move this window to the side for now
This action will open the New Profile window. In this window are several options to configure. Review each tab of settings as you like in the left pane. For the sake of this blog, we'll only configure the required General settings and the iMessage setting under Restrictions . On the General tab, type in a name for the profile in the Name field. There are other optional fields. Fill them out as desired
In the left pane, select the Restrictions tab. In the middle pane, click the Configure button. Find the Allow iMessage setting and uncheck the box
In the Apple Configurator menu, click File and select Save. Save the profile to the desktop of the Mac. Wherever you are working in the Intune management blade, copy the file from the Mac to this device
Leave Apple Configurator open as we will return here shortly to prepare devices

Step 6: Create and Assign iOS device restriction custom policy in Intune management blade

The file you just created in the last step. Rename the file extension to .XML
Going back to Intune, within the Intune blade, select Device configuration
On the Device configuration blade, select Profiles
On the Profiles blade, select Create Profile
On the Create Profile blade, type in a name for the profile in the Name field. For example, iOS Disable iMessage. In the Platform drop down, select iOS. In the Profile type dropdown, select Custom
The Custom Configuration Profile blade will open. Type in a name for the custom configuration in the Custom configuration profile name field
In the Configuration profile file field, click the blue folder icon and browse to where you copied the Apple Configurator profile in the previous step. Select the file and click Open. The File contents field will populate with the data from the file you selected.
Click OK to return to the Create profile blade
On the Create profile blade, click Create
On the Profiles blade, click the profile you just created. The profile settings blade will appear. On this blade, select Assignments
On the Assignments blade, in the Assign to dropdown, select Selected Groups. Below that, click on Select groups to include
On the Select groups to include blade, in the Select field, type in the name of the group created in Step 2 earlier. Click on the group and click the Select button at the bottom of the blade
Back on the Assignments blade, click the Save button

Step 7: Use Apple Configurator to prepare device

Before doing anything, on the device you wish to prepare, open up Settings > Click on your Name > iCloud
If an iPhone, turn off Find my iPhone. If an iPad, turn off Find my iPad
Connect the device to the Mac device with a USB cord
In the All Devices windows of Apple Configurator, the device will show up. Select the device and then click the Prepare button in the toolbar above
This action will step you through a wizard. On the Prepare Devices screen, in the Prepare with dropdown, ensure Manual Configuration is selected. Also check the Supervise devices and Allow devices to pair with other computers checkboxes are selected and click Next
On the Enroll in MDM Server screen, click Next
On the Define an MDM Server, type in a name for the MDM server in the Name field. In the Host name or URL field, paste in the URL you exported in Step 4 above and click Next. On the next screen, you will be prompted to add trust anchor certificates for the MDM server. Select the certificate appleconfigurator2.manage.microsoft.com and then click Next
On the Assign to Organization screen, click Next
On the Sign in to the Device Enrollment Program screen, click Skip
On the Create an Organization screen, type in the details of your organization and click Next
On the Configure iOS Setup Assistance screen, click Prepare. NOTE: This screen contains options that dictate the user experience after the device is prepared. If you select boxes here, the user will be presented to configure those settings during the device setup. Review each setting and determine if you organization requires that you allow users to configure these settings
You'll be prompted that preparing the device requires it to be erased. Click Erase on the prompt. The device will now be prepared. Wait for the preparation to complete. After the device has completed preparing, you can complete the setup of the device yourself and give to the user. Or, you can allow the user to complete the Setup Assistant to complete the device setup

Step 8: Use Setup Assistant to complete enrollment of device

Once the device has finished preparing, you or the user must complete Setup Assistant on the device so it is enrolled and policy applied to the device
On the device, press the home button. Depending on how you configured Setup Assistant in the previous step, you or the user will be prompted to configure the items selected in the previous section for step 11.
Select a Wifi network and connect. Alternatively, connect to a cellular network if no Wifi. Once connected, click Next
You will see a Remote Management screen for your organization. Click Apply Configuration
Type in the user credentials to enroll and click Next
You'll see a screen stating the configuration from your organization is being installed. Once this is complete, click Get Started
On the device, click on Settings > Device Management and you will see your organization's management profile on the device. This means the device has successfully enrolled and is now applying policy to the device. It may take some time for the custom device restriction policy to come and apply. Give it at least 30 minutes for the custom policy to be applied

Step 9: Validate the iOS device restriction custom policy successfully applied If you complete the Setup Assistant prior to giving the user the device. You can validate the policy is applied to the device. If you do not, you can view the data in the Intune blade for success/fail of the custom policy assignment after some time.

On the device, open Settings > Device Management > Management Profile > Restrictions
On the Restrictions screen, you will see that iMessage is not allowed on the device

And there you have it! Another adventure in Intune and the many ways we have to enroll and configure devices. Please feel free to comment and share. Until next time!

Configuration Manager - Cannot connect to the application server (HTTPS)

Matt Hinson (MSFT) — Sat, 20 Jan 2018 03:25:09 GMT

Hello all, Happy New Year! I have seen several blogs and some entries on the forums with bits and pieces of information related to the issue and solution that I will present below, but there wasn't a blog outlining this specific issue. So I wanted to put one together for those who have struggled with the issue described below. I was working with a customer this week who had an issue with their application catalog. They were using the new software center and noticed that the color scheme in the new software center had reverted back to the default blue color. As you may or may not know, the new software center still depends on the actual application catalog and application catalog web service to port deployments and color scheme into the new Win32 software center application. So, we knew there was an issue of sorts that needed to be addressed. The first thing you want to do when troubleshooting is check your logs and component status in the Configuration Manager console. Checking the components in the console, we saw both components were green. In order to corroborate this, we checked the application catalog logs, portlctl.log and awebctl.log and there were no errors. So we needed to dig a little deeper. In the SMS_CCM folder where the application catalog roles are installed on their respective server or servers, there are two directories that contain additional logs that can help pinpoint an error. The directories are CMApplicationCatalog\Logs and CMApplicationCatalogSvc\Logs respectively. In the CMApplicationCatalog\Logs location is the ServicePortalWebsite.log. In the CMApplicationCatalogSvc\Logs location is the ServicePortalWebService.log. In those logs, we immediately found clues to what the issue was. We looked at the ServicePortalWebService.log first as the web service is the foundation for the actual application catalog website to run correctly. In this log, we saw tons of red entries for this error message:

The service certificate is not provided; this could cause errors when web sites attempt to communicate with the web service. The certificate thumbprint in the web.config did not match any certificate in the SMS cert store.
FindCertificate - No matching certs found

So immediately, we now know we have a certificate issue in IIS. We scrolled up in the log to see when the error started and the error had started on 1/12/2018. We then looked in the certificate store of the server that hosted the application catalog roles and low and behold, there was a certificate that had an expiration date of 1/12/2019. What had happened was the certificate auto-renewed and the SSL binding in IIS had been lost with the certificate that expired/auto-renewed. So we bound the certificate back to the website and ran IISRESET. We watched the logs and got a little impatient so we opened Configuration Manager Service Manager and bounced the application catalog component services to expedite. Problem solved right? Well the error went away in the ServicePortalWebService.log as it found the certificate. But when we tried to access the application catalog URL, we still got the error. Next, we looked in the ServicePortalWebSite.log and saw the following error:

The client certificate is not provided; this could cause errors when the web site attempts to communicate with the web service. The certificate thumbprint in the web.config did not match any cert in the SMS cert store.

So even though we had bound the certificate, reset IIS, and bounced the component services, the application catalog was still complaining about the certificate. The next thing we did was open up the SMS_CCM\CMApplicationCatalog web.config file to try to find the thumbprint of the cert. Sure enough, the thumbprint of the cert in the web.config file did not match the thumbprint of the cert that was renewed and that we bound back to the website in IIS. For whatever reason, this value was not updating in IIS via Configuration Manager. NOTE: At this point, had we uninstalled and reinstalled the application catalog roles, it would have updated the web.config file with the thumbprint. However, we decided to update the thumbprint manually. Once we did that and saved the web.config file, everything worked as intended. In all, it took about 40 minutes to get this all worked out. However for those who are not familiar with the application catalog and how it works or where all the logs are located, this would frustrate you to no end searching the web on how to fix this issue. I hope anyone who comes across this gets some use out of it. Until next time!

Intune - Passcode Reset and Microsoft PIN Reset Service

Matt Hinson (MSFT) — Wed, 26 Jul 2017 19:06:26 GMT

Hello all, Today we are going to be talking about a relatively new feature in Azure AD that can be leveraged with managing devices in Intune, passcode reset and the Microsoft PIN Reset Service. First things first, what is passcode reset and the Microsoft PIN Reset Service? Per our documentation here:

The reset passcode capability for Windows devices integrates with the Microsoft Pin Reset Service to let you generate a new passcode for devices that run Windows 10 Mobile. The devices must be running the Windows 10 Creators Update, or later.

Let's expand on that a bit further. The PIN or passcode is a Windows Hello for Business PIN. A Windows Hello for Business PIN is required by default for any Azure AD joined devices or workplace joined devices. By default, Windows Hello for Business policy is set to 6 numerical characters that must be set after the device is Azure AD joined or workplace joined. In some organizations, this default policy is not restrictive enough and an organization can change their Windows Hello for Business policy to require a more complex PIN, such as 6 characters, alphanumeric, require uppercase letter, and a special character. The downside to more complex PINs is that it is essentially, quoting users here, "just another password I have to remember". Followed by, "what if I forget my passcode/PIN?". The forgotten passcode is a valid concern. Prior to the ability to reset the passcode, the only solution was to wipe the device and start over. Not the most elegant of solutions. I was onsite last week with a customer and passcode reset was a big item for them as they required complex PINs and were wiping devices when a user forgot their passcode/PIN. So, I got some pretty good first hand experience from assisting my customer set this up. So let's dive in on what was learned in my experience. First, if you have checked out documentation linked above, it's a pretty short article and seems rather straight forward. However, as you follow the docs, you quickly realize some questions start to emerge and the waters get muddy real quick. Azure AD cloud services, like Intune, are updated weekly and things change quite a bit. So right off the bat, following the docs, you'll see the screenshots don't match what the service is actually called when searching for it in Azure Enterprise Applications. As of this blog post, the names of the services you need to enable are:

Microsoft Pin Reset Service Production
Microsoft Pin Reset Client Production

Yes, there are two applications you need to add and they are similarly named. Ensure you enable both of them. Also, beware of the filter. If you are searching for the applications and do not find them, ensure your filter is set properly to find them. See the screenshot below: The docs also do not tell you that when you click Accept to enable the service, it sends you to a "Page not found" webpage. Cue freak out right? It would be nice if a webpage was presented that said "Enterprise application successfully added to tenant", but alas, this is not the case. After you follow the steps to enable the services, go back into Enterprises Applications, change your filter settings to show Enterprise Applications with status Enabled and make sure you see the two services showing up for your tenant. It is critical that these applications are added to your tenant if you want passcode reset to work properly. The next confusing part is the section that details the OMA-URI policy settings that you have to deploy. I've asked that this section be updated as it is uber confusing to any admin trying to configure this. First, if you were just copy and paste what is listed, it won't work because the OMA-URI setting is missing a critical component. It must contain your Azure AD directory ID. Looking at the docs, it shows the following OMA-URI setting: ./Device/Vendor/MSFT/PassportForWork//Policies/EnablePinRecovery Notice the "//" between PassforWork and EnablePinRecovery. Here is where you need to put your Azure AD directory ID. So it should actually look something like this: NOTE: The directory ID listed below is completely fabricated and is provided to show you an example of what you would actually use for your OMA-URI setting. ./Device/Vendor/MSFT/PassportForWork/9w8n7819-g233-56n2-0f36-123456789bwt/Policies/EnablePinRecovery To find your Azure AD directory ID, open your Azure AD blade in the Azure portal. Then click Properties form the menu to the left and you'll see your Directory ID. This is value you'll need to include as in the example above for your custom policy. There is also a user setting listed and the docs seem to imply that both settings need to be configured in your OMA-URI policy, or custom policy, to successfully configure your devices. However, this is not the case. You should only use the device setting in your policy. There is also mention that the setting needs to be set to True. The docs fail to call out that True is a Boolean value that you will need to set in the policy. In this section, there is a link to another article on how to create the custom policy where you would define this setting. Follow the instructions at that link along with the information above to create your custom policy. Then of course, the policy needs to be assigned, or deployed, whichever terminology you prefer, to a group. The last confusing part to our docs, there is no mention of which type of group to assign it to. For this particular policy, you can assign or deploy it to a user group or a device group, the policy will apply successfully in either case. The only real impact of assigning it to a users group versus a devices group is that a user group may contain users who have other device types enrolled such as iOS. In which case, the policy will not be applicable, but it will show as a success and inflate your status numbers. Once you create the policy, it will look something like this in the Intune portal: Ok, so that was a lot. Still with me? Because we are just getting started really! Now, let's talk about what we saw for my customer after we got everything setup properly as mentioned above. We're were ready to rock and start testing the capability. So we Azure AD joined some Windows 10 Mobile devices, which subsequently enrolled the devices in Intune, and we ensured the OMA-URI policy got applied to the devices successfully. Then we began attempting to reset the passcode on the devices: Remember our Windows Hello for Business policy we talked about earlier? For my customer, they had set a rather complex PIN requirement - 7 characters, alphanumeric, upper and lower case required, with a special character. Our experience was when we would reset the passcode for the device, we would simply see "New Passcode Pending" in the portal for the device and nothing would happen on the device: When I set this up in my test tenant prior to going to assist my customer, my experience was it took a couple minutes for the device to lock and took about 5 minutes for the temporary passcode to show up in the Azure portal. For my customer, we simply saw the above screenshot and nothing ever happened on the devices. Oddly enough, for workplace joined devices, passcode reset worked like a charm. Things that make you go hmmmmm. I wiped my device from my test tenant and Azure AD joined it to my customer's tenant. Sure enough, we could not reset the passcode on my phone now enrolled in my customer's tenant. At this point, I wasn't really sure what going on, I just knew it was something configured on the tenant or something on the backend not working properly for the tenant. Talking with some colleagues about the issue, I was pointed in the direction of using Field Medic to get some logging off the device. By the way, if your organization is using Windows 10 Mobile, I highly recommend deploying Field Medic as a required app for all Windows 10 Mobile devices. You just never know when you may need to collect some data from the device to assist with identifying an issue. Field Medic is a configurable app with all sorts of logs you can collect. As we were dealing with PIN reset, this is an event that would be captured in Security logs. So rather than collect a bunch of logs I didn't need, I configured Field Medic to only capture the Security logs. So, I fired up Field Medic, started logging, and then reset the passcode on the device again. I waited about 5 minutes and then stopped the logging on the device. Windows 10 Mobile phones are pretty cool in that you can connect them directly to another Windows device with a USB and it will see the phone as basically another drive. So I connected my phone to my Surface Book, browsed to and opened up the Security log I captured. A lot of the Field Medic logs are jibberish due to being encrypted, but there are some remnants that are useful. I wasn't really sure what I was looking for, so I decided to search for "PIN". Sure enough, I found what I was looking for. In the security log for the device, I saw the following: Microsoft.Windows.Security.NGC.KspSvc & & InvalidPinTooFewCharacters retVal [] The first entry is the passcode reset action calling the function on the device to reset the PIN. So we know the device was successfully receiving the passcode reset action initiated in the Intune portal. The second entry is the response and the most important piece of information. The return for the action was InvalidPinTooFewCharacters and it returned a value of null. Now, we don't publicly have workflows for how the PIN reset service works, but it started to make sense at this point. The PIN reset service generates a PIN and stores it locally on the device. The PIN is then sent back to Azure/Intune and it is displayed in the console to be given to the user by an admin. In this case, a PIN could not be generated due to not being enough characters. After I saw this, I will admit I felt a little silly as I simply missed when I tested in my test tenant that the default PIN complexity (based on my observation and not documented anywhere to my knowledge), is 6 characters, alphanumeric, upper and lower case required, with a special character. Sound familiar? If not, go re-read the first part of this blog about Windows Hello for Business policy. At this point, a light-bulb went off and I knew what the issue was. Recall earlier I mentioned my customer had a Windows Hello for Business policy that required 7 characters, alphanumeric, upper and lower case required, with a special character? Eureka right? The PIN reset service was not able to generate a PIN because it violated the customer's Windows Hello for Business policy - InvalidPinTooFewCharacters. As soon as the Windows Hello for Business policy was changed to 6 characters, it worked beautifully. Earlier I mentioned workplace joined devices and passcode reset working just fine even with the 7 character Windows Hello for Business policy. I wanted to understand this a bit more. If we look in the Intune console for the passcode reset command for both an Azure AD joined device and a workplace joined device, we see the action is labeled differently. For an Azure AD joined device (notice the Corporate ownership tag), the action is labeled New Passcode: For a workplace joined device (notice the Personal ownership tag), the action is labeled Reset Passcode: What does this tell us? It tells us that the passcode reset actions are different when initiated on Azure AD joined devices and workplace joined devices. As in, they call different functions on the device when the action is initiated for the device. And you can see this if you pull the Field Medic logs for both device types. As far as the internals, I'm not privy to divulge that information here, but the actions that run on the devices are not the same and that explained why it worked for workplace joined devices and not Azure AD joined devices, even in lieu of the 7 character Windows Hello for Business policy my customer had configured. All right, well that it's! Thanks for sticking in there with me and I hope you all gained some useful information from this. Happy Passcode Resetting!

Configuration Manager Report Subscription to File Share fails with "An impersonation error occurred using the security context of the current user."

Matt Hinson (MSFT) — Fri, 17 Feb 2017 22:18:13 GMT

Hello all, Hard to believe it's been a year since my last blog. Definitely a testament to how busy I've been the past year. This blog isn't really anything that one could not find without doing a bit of research. However, in the course of my research, the reference I found that helped me solved the problem was not in the normal location (TechNet or Docs) I expected. Rather, it was on MSDN. As a result, I wanted to put together a blog so the arachnids on the web could find this and make it a bit easier for others who have experienced a similar issue and could not find a reference to aide in resolving when doing a web search. Today's blog discusses an error that was presented to me by one of my customers this past week regarding a Configuration Manager report subscription that was failing to create a CSV export on a file share. Admittedly, I've never worked much with report subscriptions, but since its in the job description to help my customers out with issues, there you have it :) The most common issue with any sort of failure when creating files in a file share is usually permissions. So doing our due diligence, the first thing we did was ensure the file share permissions were set to at least Change and the NTFS permissions were set to at least Modify. Then we validated we could actually copy files into the file share. After we ensured this was correct, we ran the subscription and the following error persisted. "An impersonation error occurred using the security context of the current user." I've seen in other environments with file shares that sometimes you have to use admin share of the drive in the UNC path. For example, \\server\share is the UNC path, but you can't get to it without using \\server\d$\share. So, we altered the subscription to include this and still the error persisted. The next step we did was to focus on something simple. We created a test file share on the customer's local device where they were a local admin. Then we altered the subscription to point the customer's local file share and used the customer's account in the subscription. Same issue. At this point, I'm thinking something is not right and began to start digging into our documentation. Digging through our TechNet and Docs sites, nothing popped out for this issue. Then, I came across this reference for Configuration Manager subscriptions on MSDN of all places: https://msdn.microsoft.com/en-us/library/dn818160.aspx#Anchor_1 And it all made perfect sense at that point.

The Reporting Services service account controls subscription delivery and interacts with the account used for file share subscriptions. Windows security features restrict combinations of 1) the Reporting Services service account and 2) the account used for file share accounts. For example, if a built-in operating system account is used for the file share account, then the Reporting Services service account must be another service account with impersonation permissions. If an explicit file share account and password is configured, then the file share account requires the right to logon on to the computer running the Reporting Services service. If the file share account does not have the required permissions, subscriptions using the file share account will fail with an error message similar to the following:

“Failure writing file {file} : An impersonation error occurred using the security context of the current user.”

The issue boiled down to the account that was being leveraged in the report subscription did not have the local group policy setting set to allow the account to log on locally to the reporting services point site system. That setting is found here in Local Group Policy editor:

Once the account was added here on the reporting service point site system, the subscription was able to successfully create the file on the file share.

Hope this blog helps those who experience a similar issue resolve it much quicker than it took me to aide my customer. Until next time.

-Matt

GPO Packs in MDT 2013 U1 for Windows 10

Matt Hinson (MSFT) — Fri, 29 Jan 2016 10:49:00 GMT

Hello all, Similar to the article here, if anyone has tried to apply a GPO Pack using MDT 2013 U1 (6.3.8298.1000) for Windows 10, it fails with an rc=1 error, which means invalid function. The reason is again because ZTIApplyGPOPack.wsf does not contain code to handle Windows 10. Also, GPOPack.wsf, a script that is obtained from installing LGPO on a machine, does not contain code to handle Windows 10. So how can we use ZTIApplyGPOPack.wsf to apply a GPO Pack using MDT 2013 U1? Don’t worry, I ran into this brick wall this past week as I was helping a customer of mine who needed to apply a GPO Pack in their image build for Windows 10 in MDT 2013 U1. Attached to this blog is a zip file that contains an updated ZTIApplyGPOPack.wsf and GPOPack.wsf file that includes the lines of code needed for you to be able to apply GPO Packs to Windows 10 in MDT 2013 U1. For ZTIApplyGPOPack.wsf, replace the ZTIApplyGPOPack.wsf in your current deployment share Scripts folder with the ZTIApplyGPOPack.wsf file attached in the zip file in this blog. For GPOPack.wsf, add or replace this file in your %DeployRoot%\Templates\GPOPacks\%GPOPack% source folder in your deployment share with the GPOPack.wsf file attached in the zip file in this blog. Then ensure you update your GPOPackPath variable in CustomSettings.ini to the name of the GPO Pack you want to apply in your task sequence. Once complete, update your deployment share and that’s it. If you have an Apply Local GPO Package in your task sequence, it will be applied to your Windows 10 machine successfully. For more information on how to create a GPO Backup, reference this blog here For more information on how to create a GPO Pack, reference Brandon Linton’s fantastic blog on how to do this here Enjoy! And now, the obligatory disclaimer: © 2016 Microsoft Corporation. All rights reserved. Sample scripts in this blog are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. -Matt Files.zip

Upgrading Secondary Site Servers to SCCM 2012 SP2 or SCCM 2012 R2 SP1

Matt Hinson (MSFT) — Fri, 23 Oct 2015 12:27:00 GMT

Hello all, I was working with one of my customers this week to upgrade their environment to SCCM 2012 R2 SP1. The environment we were working in is relatively simple; single site primary with 3 child secondary sites. Primary site server upgrade went fine. And then we turned to the secondary site upgrades. I have executed several secondary site upgrades in my lab, customer labs, etc and never experienced an issue whatsoever. So I guess I was about due for an issue to pop up while executing a secondary site upgrade. And there you have the reason for this blog… to share my experience with everyone so you don’t have to go through what I did to correct the issue. First, I won’t be sharing how I fixed the issue. I just can’t, as fixing the issue requires altering the SCCM database and you should NEVER do that without being under the guidance of Microsoft Support. If you experience a similar issue as outlined below, you should immediately call Microsoft Support for assistance. However, I will share my experience with you and how we ensured this did not happen on the remaining secondary sites we had to upgrade. Background: The method to upgrade a secondary site that is documented on TechNet is to open the Configuration Manager console and go to Administration > Sites, right-click the secondary site you wish to upgrade and select Upgrade from the context menu. This action initiates SCCM to do a pre-requisite check on the to-be upgraded secondary site. There are a couple of options for viewing the pre-requisite check progress:

In the console, in the ribbon bar, there is a Show Install Status button that will record the pre-requisite check results that you can continually refresh to follow progress
You can view the ConfigMgrPrereq.log at C:\ on the primary site server

Once the pre-requisite check completes, Hierarchy Manager (Hman) wakes up to begin the secondary site upgrade. One of the first actions that occurs in the database is the secondary site information is updated to reflect the current version and build number for the site for R2 SP1, which is 5.00.8239.1000 and 8239 respectively. Once this occurs, the Upgrade option for the secondary site is then greyed out in the console and you cannot attempt another upgrade (if the secondary site upgrade fails, this is the reason why you need to contact Microsoft Support so the upgrade option can be opened back up). Hman will also check the site control file info in the database and if all checks out, will create a job to create a compressed package of the secondary site upgrade/install media for the Sender component to send to the secondary site. All of which can be seen in the Hman.log and Sender.log on the primary site server. Once the compressed package is successfully sent to the secondary site, SMS_BOOTSTRAP installs itself on the secondary site server to begin the secondary site upgrade. Once the SMS_BOOTSTRAP installs and begins the upgrade process, you’ll have 2 logs on the secondary site at C:\ that you can review, SMS_BOOTSTRAP.log and ConfigMgrSetup.log. A few things will happen with testing the connection to the SQL database on the secondary site and then a call is made to stop the site services, SMS_EXECUTIVE (SMS_Exec) and SMS_SITE_COMPONENT_MANAGER (SiteComp). Before SiteComp shuts down, it is responsible for shutting down the threads of SMS_Exec before the SMS_Exec service is stopped completely. After SMS_Exec service is stopped, SiteComp is stopped, then the upgrade occurs. The Issue: My customer and I began the upgrade on the first secondary site. We followed along as outlined above. Once we saw the send job complete to the secondary site, we logged on to the secondary site and opened up the logs to watch the progress. It didn’t take long before we saw the following error in the ConfigMgrSetup.log: <10-22-2015 16:19:56> Failed to create process of SetupWpf.exe. Looking at the lines above in the log for context, we can see why the process failed to create: INFO: Configuration Manager shutting down services: Calling StopServices() INFO: Notifying Site Component Manager of site shutdown... SMS Site Component Manager cannot stop component SMS_SITE_SYSTEM_STATUS_SUMMARIZER on component server SERVER.DOMAIN.COM. The component is probably performing clean up tasks which could take a while, clicking Ignore will terminate the component and anything that it's doing. Abort Server components are experiencing fatal errors. Why did it fail? SiteComp was unable to stop a particular thread of SMS_Exec. In this case, it could not stop SMS_SITE_SYSTEM_STATUS_SUMMARIZER. Now, I have seen similar logging like that for primary site upgrades and rather than seeing an “Abort”, you will see an “Ignore” and the upgrade of the primary site continues. But, for whatever reason, for a secondary site upgrade, if it cannot stop the threads of SMS_Exec, it just chokes on itself and the upgrade fails. So where do you go from here? Unfortunately, it’s not as simple as going back in the console and clicking “Upgrade” again due to the mention earlier regarding the “Upgrade” option being greyed out in the console. If you are at this point, you need to call Microsoft Support for help. How to Avoid: For my customer, I did some research on similar cases and I was shocked to see case, after case, after case, for secondary site upgrade failures for the “Failed to create process of SetupWpf.exe” error all due to SiteComp not being able to stop the services successfully. So, start your secondary site server upgrade from the console and quickly log into the secondary site and shutdown SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services manually or kill the processes associated with the services; smsexec.exe and sitecomp.exe respectively while the pre-req check is occurring before the bootstrap starts the upgrade on the secondary site server. On another note, also ensure you disable any AV on the primary and secondary site servers prior to executing the upgrade process as a precautionary measure. The Rest of the Story: For my customer, we did alter the database to open the upgrade option back up in the console. We also ensured we manually stopped the SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services. We then attempted the upgrade again. Well, it failed again. Following the trail of the upgrade process, we saw the pre-requisite check was successful. We then moved on the Hman and saw in the Hman.log that Hman could not upgrade the secondary site because it could not find the site GUID site definition property in the site control file info in the database. Oh boy right? Long story short, more database modification were needed, you can guess where, and after attempting the upgrade again, it was successful! The crazy part is that all of this was necessary just because SiteComp could not stop a thread of SMS_Exec on the secondary site server. For the remaining secondary sites, we started the secondary site upgrade from the console, then quickly logged into the secondary site server and stopped the SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services manually and the remaining secondary sites upgraded with no issue whatsoever. Moral: If you want to avoid a lot of headache, frustration, and a call to Microsoft Support, after you start your secondary site upgrade from the console, quickly log into your secondary site server and stop the SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services manually.