Friday, 2 April 2021

Troubleshooting in MEM/Intune (p2).

 Accessing the local log files.

When a school or business adopts remote management and mobility something becomes immediately obvious -  it’s often no longer possible to access a local machine to troubleshoot an issue. 

The device could be at home, offline or just turned off.  The user may not have the elevated privileges to run diagnostics, have concerns about remote sessions or be unable to securely transfer clear text log files over the internet. Suddenly support is a different world.

The Intune (MEM) console has a range of reporting tools that can provide insights into failed operations and these are a great place to start but sometimes you need to get hold of the local logs to get the complete picture.

On the client side Microsoft provides some excellent tools that can collate information into easily readable files. The most useful of these is MDMDiagHtmlReport.html. This can be generated by visiting navigating to Settings - Accounts - Access work or school. Find the Connected to “Your Organisation” banner and click the Info button.

The Info dialog is divided into three sections. In the last section you have the option to produce an Advanced Diagnostic Report by clicking “Create Report”. 

This action builds the MDMDiagHtmlReport html file in the C:\users\public\documents\MDMDiagnostics directory which contains information on the devices status and the policy settings being applied.

Alternatively you can select the Export your management log file link that is listed below the Connected to “Your Organisation” banner. This option goes a little bit further and creates a cab file in the same directory that contains both the MDMDiagHtmlReport file and a host of other diagnostics files including dumps of key event logs.

However useful these resources are the problem still remains that they are stored on the users computer and are not directly accessible to the support team

However a new MEM feature currently in public preview changes all of that.

If you navigate to the Devices - Window section in the MEM console and select a device, expanding the ellipses (…) should reveal a new option -  Collect diagnostics.


Selecting it will present a dialog asking you whether to collect diagnostics from the device. A simple click on the YES button starts the process.

The results can be found in Monitor - Device Diagnostics on the same device pane (below).

Initially the status will show pending but once the device picks up the request you should see the status update to Complete with the option to Download. If the device is online the action takes about ten minutes.


The process creates a zip file which you might expect to contain a set of files but instead it presents a list of directories numbered 1-50.

Since the feature is still in preview these directories might be renamed to give a better idea of the contents but at the moment it’s a bit like opening your birthday presents. A number of the directories contain a single file which is nothing more than a log of the process that created the rest of the logs (logs of logs) but some are much more useful.

All this could change but at the moment some of the highlights are listed below.

Spoiler Alert:  the MDMDiagHtmlReport can be found in a cab file in directory 44.

 


  • Directory 1 -11

Dumps of registry entries (.reg).


  • Directory 12 -27

Logs files for the collection actions (logs of logs)


  • Directory 28 -37

Dumps of various Event logs. (.evt)


  • Directory 38:

A set of event traces data files relating to Autopilot. To view an etl  file open with PerfView.exe.


  • Directory 40

Contains mpsupportfiles, a cab file that contains various diagnostic logs and event dumps relating to Windows Defender.


  • Directory 41:

The wlan-report-latest html  report created by the ‘netsh wlan show wlanreport’ command that shows wireless session information and related stats. 

Apart from a wealth of information in the hardware interfaces it contains a dump of the output from 'ipconfig /all' and ‘netsh wlan show’ -  two of the most useful tools in the box.


  • Directory 43:

The energy-report.html output file created by  powercfg /batteryreport tool useful in troubleshooting laptop battery usage and health.


  • Directory 44:

Holds a single file  mdmlogs-xxxxxxxx.cab which contains the files created by the Export your management log file link including the important MDMDiagHtmlReport file.

Other files include:

DeviceHash_<devicename>.csv - contains the device hash.

Setupact.log - Information and log events from upgrade actions.

Intune Management Extension logs.

  • AgentExecutor.log
  • ClientHealth.log
  • IntuneManagementExtension-xxxx.log

Event logs from key MDM providers.


  • Directory 45:

Log file output from the msinfo32.exe tool which summarized the hardware and software profile of the device.


  • Directory 48:

Cbs.log : Component-Based Servicing Log. This file contains detailed information from the most recent Windows installed updates.



Hopefully the directory set will be updated to make navigation through the file a bit easier. However even in the preview phase this is a welcome addition to the troubleshooting toolkit.


Thursday, 11 March 2021

Troubleshooting in MEM/Intune (p1).

Basic Troubleshooting.

When IT admins are first presented with a problem it normally comes in a user centric form.

For instance;

William Gates can't access the finance package from his new laptop.

Probably 90% of all tickets are made up of users complaining that they can’t access a resource or something linked to their logon account is not working as they expected.

Unfortunately most management consoles (and MEM is no exception) are organised from an application or service centric viewpoint which can make it hard to get an overview from a users perspective. You can end up ping-ponging around the console opening up one service dialogs after another trying and get a handle on the issue but getting nowhere.

There is however, an excellent resource that should be the first port call for all help desk operatives - the well named but rarely visited Troubleshooting + support tool.



This might sound obvious but there is a tendency to drive straight into the detail without first gaining an general overview. The advantage of the Troubleshooting + support tool is that it organises information from the user perspective, summarising a wealth of information in an easy to read manner. Since most issues are caused by something stupid this can reveal the problem straight away. 

The top level dialog shows basic account information including whether the user has an Intune licence, a list of group memberships, application allocations, registered devices, application protection status and enrolment failures.


The drop down provides data on a number of other key areas such as compliance and configuration policies and enrolment restrictions and a number of other key areas.  Selecting the information takes you directly to the service configuration dialog page which is a real time saver.

A good approach would be to find a user that works and then use the summary features of the Troubleshooting tool to find the difference between the two user states.  It’s not going to work all the time but it's a recommended first step.

Part 2: Accessing the Local Log files.

Monday, 1 March 2021

Universal Print Revisited.

The print subsystem is one of the last hurdles that a school or business needs to overcome to remove the dependence on on-premise servers.

Ideally the collaborate workflow and document sharing mechanisms of platforms such as Microsoft 365 and Google Workspace will eventually replace the traditional method of transferring data using wood pulp but that may be a little way off yet.

In the interim, Microsoft has introduced  Universal Print, a system similar in architecture to the now defunct Google Could Print that allows Windows 10 users to print to a device anywhere on the network through a cloud based connector.

A number of excellent blogs and video resources have been created that explains how Universal Print works but it's worth repeating a couple of points.

Universal Print (UP) is still in development and is missing some key features. The most obvious being that native hardware support is missing from most printer ranges. In fact, at the time of posting I can only find one manufacturer Lexmark that supports UP through a firmware update.  The models are listed here.

Licencing for Universal Print is bundled as part of the Microsoft E3 licence. Schools looking to move to Modern Management should be adopting Microsoft E3 as standard. If your school subscribes to Office 365 with Enterprise Mobility + Security this is not enough to get Universal Print. For each user that accesses a printer you'll also need Windows 10 E3, E5, A3 or A5. The client also needs to be running Windows 10 version 1903 or later.

Universal Print doesn't currently support 'Follow-Me' or ID card management. You'll need a bolt-on service like Paper-Cut to provide that. This feature is pretty much top of the product roadmap as it's absence is a show-stopper for any type of enterprise deployment. 

Lastly, the mapping of printers through Intune (Endpoint Manager) is a little clunky. I'm pretty sure this is by design, Microsoft doesn't want you to be printing or mapping local drives in the future. However it can be done and this useful post shows how.

   Deploying Universal Print Printers With PowerShell & Intune

So work in progress. If you need a simple system that supports basic print functions without the inconvenience of a local print server Universal Print, even in the preview form might be for you.

Thursday, 25 February 2021

First Look at Azure Active Directory Connect Cloud Sync

New schools setting out on the Microsoft 365 platform can look forward to a future without on-premise servers, using Azure AD as the directory service and InTune (Microsoft Endpoint Manager) for device management. 

For existing schools, moving to the cloud while maintaining on-premise Active Directory isn't quite so easy.   Local resources such as printers and file shares are protected by local AD while cloud resources require Azure AD accounts. This means two different user databases that have to be maintained and updated.

Fortunately Microsoft has always provided an application to make this job easier. 

The best known is Azure Active Directory Connect (AADC), a tool that has been ‘rebranded’ several times over the years.  Administrators may also know this utility as the Directory Synchronization tool, Directory Sync tool or just DirSync.

Basically AADC is an application that synchronizes the on-premises Active Directory Domain Services (AD DS) users to the Azure AD tenant. As well as account provisioning it can also transfer a password hash that delivers a seamless logon experience for the user across both platforms. Although it's possible for changes to move in the opposite direction (password updates in the cloud are reflected in local AD) for most setups this is a one way trip - changes in on-premises Active Directory are reflected in Azure AD.

Azure Active Directory Connect has been a workhorse for Azure deployments but it has a number of limitations, some of which are particularly relevant for schools.

First, only one instance of AADC can be attached to a single Azure AD tenant. For larger educational trusts that are planning to consolidate multiple sites, each having their own Office365 organization, this provides quite a challenge. Currently the only solution is to ensure network level connectivity between the domain controllers in each forest so that the sync requests can be channelled through a single AADC instance. For medium sized companies that have a corporate WAN in place this isn’t a problem but for an educational trust trying to incorporate a dozen small primary schools, all using different internet providers, it’s a major headache.

Second, AADC requires a hosting device and in some cases that means dedicated server. If the school requires resilience or some degree of fault tolerance you now need two servers. For schools running a virtual infrastructure that requirement can be absorbed but for smaller sites it’s an unwelcome burden

Lastly although the ease of setup has improved over the years some expertise is still required to install and configure AADC which is largely managed through the onsite application rather than the cloud.

In response, Microsoft has rewritten Azure Active Directory Connect (AADC) from the ground up to create Azure Active Directory Connect Cloud Sync (AADCC).  Disregarding the confusing naming convention this new addition is a real winner for education

Lets run through a few of the new features.



First, AADCC can work alongside existing installations of AADC, This is because multiple instances of AADCC can connect to a single Azure organization, each managing a separate domain namespace, a killer feature which removes one of the biggest limitations of AADC. In the new model a fully detached AD forest with AADCC installed can feed into a single centralised tenancy, no WAN required.

Second most of the configuration and logic has been moved into the cloud meaning that the local install is extremely light. The only requirement is domain-joined Windows 2012 Server with SQL Server 2012 Express LocalDB (a smaller version of SQL Server Express) installed.

Lastly the software has no additional licencing requirements and has a simple deployment model. Installing multiple active agents provides high availability

How does this help the adoption of Modern Management techniques in a Trust or District model?

Up until now amalgamation of schools into unified tenancy model has been hampered by the fact that only one site can host the AADC. A second site that wished to run with hybrid identity would need ‘line-of-site’ of the hosting sites domain controllers. 

So long as all the other sites only used ‘cloud only’ user accounts you didn’t have a problem but if two large schools, both with a detached AD forest wanted to move to Modern Management while maintaining access to local file shares through hybrid identities, you had a problem - until now.


So what's the drawback to using AADC over AADCC ?

The new tool does not allow Pass-Through Authentication. Currently passwords are checked against a password hash stored on Azure. Also there’s no support for writeback for passwords, devices or groups but other than those two items the functionality is much the same. 

This video from the recent Ignite Conference gives a good overview which includes some configuration and install instructions.

It’s hard to overestimate the importance of this new capability to the adoption of Microsoft Endpoint Manager as a viable management platform.


Tuesday, 2 February 2021

Managing Local Groups with InTune

For most IT administrators control over local user groups is an important part of the management process. Unfortunately for Windows devices that are Azure joined this has always been a bit of a challenge.

Working with InTune there was a CSP Policy - RestrictedGroups that you could use but it had a number of limitations.

  • It didn’t support groups, only user accounts.
  • It had an overwrite feature – it simply replaced the original user list with users in the policy set so the results were a little unpredictable. If a user account had been added to the Local Admins group to support a legacy application it would be removed when the new policy set was applied. You couldn’t create policies that layered accounts into the group.
  • It only controlled the local Admin group, not any of the other in-built local groups.

However with Windows 10, version 20H2 you get a new feature – the ability to control access to local groups by nesting an Azure AD security group.

The initial setup is a bit of a challenge but once done it’s a useful tool to have at your disposal.

The first job is to create a Azure AD security group to contain your new local admins, let's call it  - All Additional Local Device Admins.

The second task is to find the SID of your new group.

Unfortunately you can’t read the information from the web UI because it doesn’t display the SID.  However it can be found with the Graph API/ Explorer using the Group Object ID which is presented as part of the Group properties page.


With the Object ID recorded, login to the Graph API/ Explorer and run a GET query using the form of the request below.

https://graph.microsoft.com/v1.0/groups/<your Group ID>


 

The group metadata will be displayed in the results window and this will include the SID. Record this value.

This next task is to create a policy that uses the SID to embed your AD Azure group into the local Admins Group.

Navigate to 

        Microsoft Device Management (Intune) - Devices - Windows - Configuration Profiles

Create a new Configuration Profile - type Custom. Provide an appropriate name and description.

Add a new OMA-URI setting using the ID below for the OMA-URL identifier.

       ./Device/Vendor/MSFT/Policy/Config/LocalUsersAndGroups/Configure

 

The payload for this policy is in the Value field.

It contains a snippet of XML that defines the action. The options that you can incorporate can provide a lot of flexibility allowing you to add or overwrite the contents of any local group but for the moment let's keep to the original requirement to update the local Admin group.


<GroupConfiguration>

<accessgroup desc = "Administrators">

<group action = "U"/>

<add member = "S-1-12-1-3360748891-1147449691-4205429123-2160019913"/>

<remove member = ""/>

</accessgroup>

</GroupConfiguration>


The code contains the instructions to update “U” the “Administrators” group by adding the SID “S-1-12-1-3360748891-1147449691-4205429123-2160019913” which we already know references the Azure Group All Additional Local Device Admins

The XML has a number of different action types including Restrict “R” which provides the same functionality as the RestrictedGroups/ConfigureGroupMembership policy setting.

You can get full list of actions and options here.

Save the policy and assign it to a suitable Device security group. There’s no option to select a single device so it’s best to test it out on a test group first before trusting your luck (and job) to All Devices.

You will now find that adding an Azure AD user account to the All Additional Local Device Admins group will grant admin rights on a policy refresh. Even better, removing the user will remove admin rights on the next login.

If you use the local MMC to view the members of the Admin group you can see the new Group account added, but only as the SID.The name is not resolved.

Of course there’s no reason why you couldn’t use the same technique to control the membership of other local groups such as Backup Operator. Just be aware that although this works with all Windows 10 editions, other than Home you need to be on version 20H2 to get this new feature


Friday, 29 January 2021

Managing Policy in G Suite and Intune

Following on from some earlier posts looking at the management process in both Microsoft InTune and Google Workspace it’s worth having a closer look at user and device policies because the models diverge quite a bit at this point.

In Google Workspace there is a clear division between a policy that applies to a device and one that affects the user experience. In fact, other than a few examples I can think of the two policy sets are completely unique.

If you then move into the Microsoft space this division breaks down entirely. Here you have a single unified policy set which can be applied at either the device or user level.

To give an example, using the Microsoft approach you are able to set a policy which controls an aspect of the user environment and apply it at the device level. The result will be that the feature will be set regardless of which user logs on.

Using Google Workspace that's not possible. You can’t set a policy that controls the user experience and apply it to a specific Chromebook. 

Google Workspace has a kiosk mode which does something similar but this does not apply to authenticated user sessions.

Although this sounds a little restrictive it does make things easier to maintain and troubleshoot. You never have to check if a policy is being set by the device or the user object and there is never any conflict resolution.

Not surprisingly Microsoft suggests an simple approach to user and device policy.

“If you want to apply settings on a device, regardless of who's signed in, then assign your profiles to a devices group. Settings applied to device groups always go with the device, not the user.”

“Profile settings applied to user groups always go with the user, and go with the user when signed in to their many devices.”

The difference between the two platforms is that while Google Workspace imposes these rules, with Microsoft it's just a recommendation. Microsoft provides flexibility but this comes with added responsibility and complexity.

A second major difference is that, in general, Microsoft policies are applied through a group structure You can create a policy and then apply it to single or multiple groups and those groups can be nested.  To also have the ability to create groups that contain users  - and groups that contain devices and apply both to the same policy set. One last level of complexity is that groups can be be marked as either applied or excluded for each policy - with exclusion taking precedent,

Now just because you can do these things doesn’t mean you should and in fact there are good reasons why you really shouldn’t.

Again Microsoft best practice strongly recommends you do not mix grants and exclusions using user and devices groups as the results “may not be what you want or expect”. They provide a useful table which is really no more than common sense.

Keeping it simple and granular is going to be the best approach working with Microsoft policies.

For both users and devices Google Workspace uses a hierarchy of organisational units to apply settings. Policy is determined but the object's position in the tree and the inheritance at that level. The major advantage of this approach is its simplicity and ease of troubleshooting but it can be difficult to incorporate exceptions to the rule. For this reason Workspace is stealing a page from Microsoft and incorporating the concept of group exclusion. A user set can have a policy applied based on the location in the OU tree but the setting can be overridden by group membership.

Typically, you would apply services settings to OU's and then make exceptions for some users. For example, you can restrict YouTube content for accounts but let some groups view all videos or approve videos. In all cases the policy set by the groups overrides the policy set at the OU.

Not all services allow this function. The ones most commonly used by education include ;

  • Directory (Profile editing)
  • Calendar
  • Currents
  • Drive 
  • GMail
  • Google Meet
  • YouTube

Since Google Workspace has no concept of a device group these actions apply to users only.

Lastly both platforms have a different way of handling policy negation.

Google Workspace administrators are used to working with policies that have distinct values (ON/OFF) with each setting having a default value. Also since each device or user object must exist somewhere in the OU tree every policy has a setting. The amalgamation of all the settings  defines the profile.

This isn’t the case in the Microsoft world. The policy set is a variable array with elements being added or removed as an assignment moves in or out of scope. The challenge occurs when a policy sets a value to ON but then moves out of scope without another value being explicitly set.

Does the values return to the original setting, a default or remain the same ?

The answer is “it depends”.

The settings are based on Configuration Service Providers (CSP) and each CSP can handle profile removal differently. Some might revert to default values, others do nothing. Microsoft's advice is to work explicitly with each value that needs precise control.

For instance if you have restricted a user from a desktop service, simply removing the user group from the policy scope may not be enough to grant access,

To change a setting to a different value, create a new profile, configure the setting to Not configured, and assign the profile to the device. Once applied to the device, users should have control over the service,


Microsoft InTune and Google Workspace, two management models, each with their own strengths and weaknesses. Not better, just different.