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.<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.



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.


<accessgroup desc = "Administrators">

<group action = "U"/>

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

<remove member = ""/>



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.