Friday, 2 August 2019

Azure AD Registered Devices, Intune, Sync could not be Initiated (0x82ac019e) and Port 444


I've been very busy so a new blog post a little later than I really wanted to.. But this should help people that get the terrible error for Azure AD Registered Windows 10 devices of 'The sync could not be initiated (0x82ac019e)'.

Nearly every post on the internet for this error relates to an unlicensed user. However that's not actually always the case, in this instance it was a firewall configuration issue.

The device was Azure AD Registered by simply connecting a Work or School account to the device, however upon doing so and trying to force a 'sync'. This error presented itself.

Checking Event Viewer under | Applications and Services Logs | Microsoft | Windows | DeviceManagement-Enterprise-Diagnostics-Provider | Event ID 201 stated there was an issue registering succesfully.

Trying to get to the Azure AD registration url gave the following error.

Similarly after installing the Telnet Client the Windows 10 device couldn't open a connection.

This became evidentally clear that this was a port issue, most likely firewall related. After opening port 444 the Windows 10 device could talk successfully to

and Event ID 209 showed a succesfully registration

And under | Settings | Accounts and sign-in | Connected Accounts | Info | If I selected 'Sync', it would now synchronise succesfully.

And my device was succesfully Azure AD registered!

As there were already succesfully Azure AD joined devices it became clear that there is a difference in the way both operate. Azure AD joined devices talk over port 443 which is almost always open on the firewall for outbound traffic.

Azure AD registered devices talk on port 444. You will most likely find this port is blocked in enterprise environments, and if it is, you'll need to open it.

Have fun,

Tuesday, 16 April 2019

I have AADConnect Directory Synchronisation and users do not provision for Skype for Business Online

Just a quick one this morning. I recently I had an issue where a customer did not have users being provisioned for Skype for Business Online. The customer had remnants of a legacy Lync 2013 on-premises deployment and they were using AADConnect for directory synchronisation.

Digging in the tenant I could see that even with the Skype for Business Online license enabled, even after waiting several hours if I used Get-CsOnlineUser in the Skype for Business Online Management Shell, no users were there.

This led me to my good friend Jaap Wesselius Blog Post here - Aha, a possible eureka moment! This must be the issue. Unfortunately it wasn't, however it was this attribute that ultimately resolved the issue and led me to the resolution.

It appears since Jaap's post further logic and evolution has occured in the service, and these previous on-premises Lync enabled users could not be enabled for Skype for Business Online anymore using the above solution.

What I had to do was actually set the msRTCSIP-DeploymentLocator attribute to '' - once this was done the user would provision. Interesting as no previous Lync Hybrid deployment was in-place or had been attempted. It appears to be logic in the service for users that were previously enabled for Lync or Skype for Business on-premises.

Anyhow to cut a long story short, I wrote a little script to do this. I utilised a CSV file to import my users, as I didn't want to perform this operation across all user objects in the Active Directory. Similarly if you are planning to perform a cutover from on-premises Lync or Skype for Business rather than a Hybrid deployment and migration - again this will come in handy before you deprovision the users in the on-premises service. Just make sure you export the list of users via Get-CsUser first. Of course if you do plan on wanting to write across all user objects then substitute the first line "$users =" with Get-AdUser or similar rather than Import-CSV.

It's fairly self explanatory - And remember, even if you don't plan on using Skype for Business - be aware that Microsoft Teams still has some reliance on the service for services such as voice. So you will want to ensure there's no issues to provide your tenant and users a smooth Teams experience.

$users = Import-CSV -Path C:\yourfilehere.CSV
ForEach ($user in $users){
$u = $User.samaccountname -replace '"',''
Set-ADuser -Identity $u -Replace @{'msRTCSIP-DeploymentLocator' =  ""}}

Thursday, 11 April 2019

Enabling Azure Information Protection Unified Labelling Preview

Microsoft currently have Unified Labelling in preview, but if you are looking at migrating your Azure Information Protection labels over to the Compliance Center what do you need to do?
First and foremost I would advise against do this in a real in-life tenant right now unless you are well prepared and ready for users to utilise it in Office.

Migrating the labels and having a Unified Labelling experience is one thing, but currently not all settings are migrated and you have to check each migrated label with care and attention - and reconfiguring the labels as and where necessary.

If you have a test Office 365 tenant however, this is a great place to test the unified experience to help plan for when the service becomes generally available, and will also allow you to test out the experience in Microsoft Office clients with the Unified Label plug-in.

So - how do we unify the label experience to help us plan for the change as a administrator for when Microsoft push this change to the service later in the year?

First things first, let's take a look at what's in the Compliance Center | Classifications | Labels. You will see these have now been split into 'Sensitivity' and 'Retention'.

In my test tenant, any previous labels I had created before this change would have been for Retention only, as Sensitivity was not an option. So you can see I have zero Sensitivity labels available.

So how do we migrate labels from the Azure Portal to Compliance Center? If we login to the Azure Portal and select Azure Information Protection, you'll see 'Unified labeling (Preview)' at the bottom of the blade. You'll see that it is a one way process and cannot be undone was activated, you'll see any labels with duplicate names across the service will be renamed (so best to check this, or test it out like I did). The one thing it doesn't state is not all your settings are migrated over! Which is pretty poor to be honest and something it should absolutely state You can read up about this further at this AIP documentation.

Let's take a look and then activate.

Once activated you will see your AIP labels appear in Compliance Center under 'Sensitivity'.

So comparing the migrated labels you'll see some settings are migrated, and others are not. So make sure you verify each and every migrated label. However it is generally pretty good at carrying most things over. Confirm all protection settings and headers and footers to re-affirm your configuration settings.

You can see for example the encryption settings and users specified for a label have been carried over succesfully in this example label.

So once you have tested the experience, you now need to ensure you have downloaded and installed the unified label plug-in for Microsoft Office. It requires a specific version of .Net and there's a specific KB to install to allow it to work on Windows 7 machines. It also supports Office 2010 which is a surprise too - you'll find all the caveats to these here.

Have fun!

Friday, 15 February 2019

Using Azure MFA Server as an SSL LDAP Proxy

This post outlines the steps required to initiate your on-premises Azure MFA Server deployment as an SSL LDAP proxy for Active Directory. This allows MFA to be put 'in-line' for anything authenticating to Active Directory via LDAP - a useful solution for legacy on-premises applications that cannot support MFA through an update or migration to an Azure MFA supported solution such as an Azure Enterprise Application.

This post assumes your Azure MFA solution is deployment and working on-premises. From this base working profile, we perform the following steps to enable it as an SSL LDAP Proxy.

In the Multi-Factor Authentication Server console select 'LDAP Authentication'. From here we need to select 'Enable LDAP Authentication. Standard LDAP port of 389 and SSL LDAP of 636 should be entered.

If using SSL LDAP, we must enter a trusted third party certificate or one that is provided from a valid internal PKI infrastructure, such as Active Directory certificate services. If it is a self signed certificate, please note the service will not start and you will cause issue for your LDAP proxy and it will not listen on either 389 or 636 (or alternative ports if you have configured them). Please also note that you must restart the server at this stage to have the LDAP Proxy service start.

We then need to also 'authorise' clients that can connect to the LDAP Proxy service. Simply select 'Add' under the clients section and add the IP address and specify an application name to provide a basis of understanding for the client that is connecting.

One thing to remember here is if you want the LDAP Proxy to only support users that have enrolled for MFA, you should select 'Require Multi-Factor Authentication user match'. If you leave this unchecked it will allow users that haven't been enrolled for MFA to also be able to use the LDAP Proxy, and of course be allowed to authenticate with only their username and password. This is a good setting if you want to front the LDAP Proxy immediately and slowly enroll users into MFA.

We now need to change 'Directory Integration' from 'Use Active Directory', to 'Use specific LDAP configuration'. You will need to specify a server, Base DN of your Directory and use a sufficient account to perform a BIND with on behalf of the Azure MFA Server Proxy service. You can then use 'Test' to test a succesful connection and bind operation to your Active Directory.

And that's it, the LDAP Proxy service is configured. So how can we test it before pointing applications that use LDAP authentication to it? Well we could use test applications of course, but you can always use LDP.exe to perform a simple LDAP authentication test.

Open LDP.exe and select 'Connect', enter the IP address of the LDAP Proxy and specify the port and whether you have implemented SSL or not.

Once connected perform a BIND using the credentials of a user you want to test. If you have configured the LDAP Proxy to allow authentication for users not registered for MFA then you will authenticate as normal - just as if you had pointed LDP.exe at a Domain Controller.

If however the user has been enrolled for MFA, prior to getting authenticated to the directory you will be prompted on your multi factor authentication device! Either phone, text of the Microsoft Authenticator App. I of course use the App as it provides the best experience, so after selecting 'Approve', I am authenticated.

If you are using phone or text as a second factor mechanism - consider upping the timeout settings to 30-60 seconds to not receive a timeout before the user has a chance to respond.

Finally I wanted to talk about enabling the LDAP Proxy service when you have Azure MFA Server and you are using ADFS. If Azure MFA Server is installed on your ADFS server farm, combining Azure MFA Server and ADFS is a supported topology. However if you plan to deploy a non-SSL LDAP Proxy service and plan to use port 389 this will conflict with ADFS and break it.

It is best to seperate Azure MFA Server when using LDAP Proxy rather than have it installed on an ADFS server. You will most likely have to split Azure MFA Server to dedicated servers as using non-specific ports may make use of the service less than ideal with your applications that require LDAP authentication.

Have fun!

Friday, 8 February 2019

Using the Win32 Application Packaging Tool for Intune deployment

First of all Happy 2019!

Hopefully by now you are using Microsoft Intune to manage some of your device estate - even if the concentration is purely for mobile and tablet MDM purposes. Intune is a great way to manage Windows 10 devices - especially with Autopilot and AAD joins. But how do you push Win32 apps to your devices?

In comes the Win32 Application packaging tool. You can get the build from Github here.

It's fairly easy to use to convert your msi and exe files to the .intunewin standard for uploading into the Intune console.

In this example I am packaging Notepad++, in the root of the folder that houses the IntuneWinAppUtil.exe create a folder that houses the application you want to convert, ensuring any ancillary files are included, and also create another folder to push the converted file format out to.

From here open PowerShell or the command prompt and run:

"IntuneWinAppUtil.exe -c "Source Folder containing the application files" -s The name of the .exe -o "The output folder to put the .intunewin package to"

The switches are explained below, and -h is for help.

Sample commands to use for the Microsoft Win32 Content Prep Tool:
IntuneWinAppUtil -h
This will show usage information for the tool.
IntuneWinAppUtil -c -s -o <-q>
This will generate the .intunewin file from the specified source folder and setup file.
For MSI setup file, this tool will retrieve required information for Intune.
If -q is specified, it will be in quiet mode. If the output file already exists, it will be overwritten.
Also if the output folder does not exist, it will be created automatically.
If no parameter is specified, this tool will guide you to input the required parameters step by step.
Command-line parameters available
-h Help
-c Setup folder for all setup files. All files in this folder will be compressed into .intunewin file.
Only the setup files for this app should be in this folder.
-s Setup file (e.g. setup.exe or setup.msi).
-o Output folder for the generated .intunewin file.

It will then package your file.

And you'll have your .intunewin packcage to upload to Intune.

You'll now be able to upload the package to the Intune console.

Have fun!

Wednesday, 19 December 2018

Why does AzureAD advanced reporting and Azure Identity Protection give me conflicting alerts?

This is for any Office 365 Administrator that is using the advanced reporting features of Azure AD Premium P1 and also Azure Identity Protection as part of Azure AD Premium P2.

If you are using this reporting functionality from AADP1 and AADP2 you will no doubt be getting reporting conflicts where Azure Identity Protection is reporting suspicious activity even though you have ring fenced your networks and locations in the Azure Portal. This is a confusing and annoying anomaly that will frustrate you, but here's the answer to the issue. Azure Identity Protection, also known as the Cloud App Security Portal, doesn't honour any of the name locations or trusted locations you have setup in Azure Conditional Access | Named Locations.

Let's take a look!

Here you can see I am in the Azure AD Admin Center. Utilising the advanced reporting features of Azure Ad Premium P1 allows me to get more granular reporting capability from Azure on what is happening in my tenant and how users are authenticating and access Azure and Office 365 services. One of the great features here is adding 'known IP address ranges'. As shown below.

Selecting this takes me to Azure Conditional Access, where I can configure named locations. You can see I have configured my locations below as any good administrator should as this information is used to filter alerts and give information to the system to provide fine tuned alerting to you. When you add a named location in you also have the option of making it trusted - for example to bypass MFA requirements for 'trusted locations' rather than having to specify individual locations that come from this list.

So once I have populated all of this information my advanced reporting features of Azure AD Premium P1 will start to use them - and my alerts will take into account the configuration I have placed here. But what about Azure Identity Protection which is a feature of Azure AD Premium P2?

Well the truth is it doesn't use this configuration data at all - which is a crying shame. You have to configure it all over again. Let's log in and take a look.

You can see I am getting alerts for my Washington Office here, even though it's configured and trusted in the named location section of Azure Conditional Access in the Azure Portal.

So how do I remedy this so I have a unified advanced alerting capability and identity protection platform?

Well you need to add the locations into the Cloud App Security Portal. Specify the cog in the upper right area of the Cloud App Security Portal and select 'IP address ranges'

From here you will have to enter your locations once more.

Once entered, Azure Identity Protection will be able to use these locations in any of the pre-canned policies, or indeed any custom ones you create, to provide the same insight data that you are getting from the advanced reporting feature of Azure AD Premium P1.

And that's it. No more alert conflicts between the two systems where advanced reportings understands that a network is trusted and you get conflicted information from Azure Identity Protection.

The only downside is you will need to remember to update both until Microsoft ingest Azure Identity Protection fully into the Azure Portal (which I hope they will do!) and they share the same metrics and configuration data. Until that time, administer both.

Have fun!

Thursday, 22 November 2018

Mitigating Azure MFA issues during outages for Azure MFA, Azure Conditional Access and Azure MFA Server

Microsoft suffered a very unfortunate Azure Multi Factor Authentication issue on November 19th which affected thousands of their customers for many hours. In a world where MFA is a must, even if most tenants still don't use this fantastic feature, and the service breaks, how do we mitigate the service issue that we experienced?

Well the first thing to understand is what version of Azure MFA are you using? There's effectively 3 versions in Office 365 which provide additional features and functionality via licensing: Azure MFA, Azure MFA Premium - although this cannot be purchased anymore as of October 2018, and Azure Conditional Access which allows MFA in it's workflows. On top of this there's also Azure MFA Server, an on-premises product to contend with as well - which was also affected by the outage.

So in a future scenario where we could have another Azure MFA outage, what steps as an Administrator can we take to gain access to our tenancy as well as mitigate user sign-in issues?

Let's take a look..

So from a user perspective, and we're just using the standard Azure MFA solution here, they won't be able to sign-in as MFA will be enforced. If you have legacy Azure MFA Premium licenses in play still or have Azure AD Premium licensing you'll find you can add trusted locations under 'service settings'.

So we now have two options, providing the service is still honouring trusted locations, which on the November 18th outage it was, we can setup some additional locations like the IP address of the user that's working from home. Or we can temporarily disable the user. Once the outage has recovered we can then go back and enable them once more. Remember to select 'restore multi-factor authentication on all remembered devices' so they won't have to re-register their device which can cause employee confusion.

If the users are logging into Office 365 and we have utilised Azure Conditional Access to create an MFA workflow, then the legacy Azure MFA page as shown above will show the users as disabled for MFA - but they will very much be enabled. To get this information on who is enabled you will have to dig through Azure AD Powershell.

In regards to getting the users access to their services again will require you to relax the MFA workflow in the Azure Conditional Access rule set, or disabling the rule altogether until the outage is over.

To relax the MFA requirement search under | Access Controls | Require multi-factor authentication

To disable the conditional access rule simply toggle it to OFF under | Enable policy

So your users sign-in issues are now resolved, what about your administrators? The answer here will lie somewhere above depending if you simply use the standard Azure MFA management page or if you manage an MFA workflow through Azure Conditional Access - however I would expect you to have a seperate conditional access rule for your Administrators, VIPs, Finance Teams etc.

If you are in the position where you cannot actually login to your tenant at all to make the above changes then you should have an account that allows Global Administrator access to your tenancy where it's details are unknown and locked into your BCS process. I recommend the standard * account here. If you are utilising Azure Conditional Access ensure you have setup an exclusion policy - which is actually Microsoft best practice for this very reason.

This is especially important if you have Customer Lockbox enabled - as Microsoft won't be easily able to help you gain access to your tenancy!

So finally that leaves Azure MFA Server. In the scenario encountered on November 19th how can we mitigate sign-in issues when Azure MFA Server is in use and users are enabled through it?

Simply open the Multi-Factor Authentication Server console, select Users | User and we can disable MFA altogether if we so wish until we want it enabled once more.

We also can utilise Trusted IPs and skip MFA requirements for them - just like in the Azure MFA service. We must however configure the IP addresses in the Multi-Factor Authentication Server console. Select | User Portal | Trusted IPs | and enter them here.

However there are other ways still. We could simply enable 'one time bypass' so MFA is still enabled but the user when they try and login to Office 365 during the outage will not get prompted for MFA.

Ensure you have an account that is a Portal Administrator

Once the admin is logged into the User Portal they can simply find the user and initiate 'one time bypass' and a time in seconds it will stay active before turning off the bypass. 300 seconds is the default. The next time the user logs in, MFA is not required, and then subsequently enforced once more.

So is there any other ways? Yes - and one from the outage that it is worth ensuring you keep enabled. Ensure under | User Portal | Settings | Use security questions for fallback | is checked. This will allow a standard security question response in the event of Azure MFA failure.

Take care,

Friday, 28 September 2018

Controlling access to the Outlook on the Web Beta Experience

Exchange Online customers are now having users being asked to trial the new Beta experience for the service once more. But what happens if this causes confusion in the work-place and introduces higher help desk calls? What happens if you are the IT Administrative function and you want to control when this experience is rolled out to your users?

Well the good news is we can control it with Outlook Web App policies and some Powershell..

Users are now getting asked to trial the new experience in the upper right area of their Outlook on the Web experience as Microsoft has pretty much rolled this out to all tenants in Office 365. Users will have been accustomed to the below experience for quite some time

The new 'beta' experience, introduces a look and feel that is almost exactly what consumer users of have been experiencing for the last 6 months.

We can control this by removing the option to users by utilising Powershell and editing the default Outlook Web App mailbox policy or creating a new one and assigning it to users. You may even have multiple policies already in place and need to make multiple changes. Here's what a user logged into Outlook on the Web looks like with the option removed.

So why do we need to use Powershell to modify this feature? This is because you cannot control the Outlook Beta Experience in the Exchange Administrative Center - the feature control isn't there.

So open a Powershell connection to your Exchange Online tenant and let's use Get-OwaMailboxPolicy to check the policies you have in-place. You will most likely just have the default policy, unless you have created additional ones in the past.

We're specifically looking for 'OutlookBetaToggleEnabled'

If you want to make the change against the default policy simply utilise this command

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-default -OutlookBetaToggleEnabled $false

And that's it we're done. If you have multiple policies in play then make sure you do it for each, or if you want to control roll out you can create a new policy with the feature disabled, then set it to specific users using the Set-CasMailbox cmdlet. For example:
Set-CASmailbox -Identity -OwaMailboxPolicy "Policy Here"

Don't forget though, this change is coming and will wholly affect Kiosk and F1 plan users - so don't remove the feature and forget about it. Utilise this to control the experience whilst you inform users of the change.

Until next time,