Monday, 18 November 2019

Working with Read Receipts in Microsoft Teams

Microsoft announced in July 2019 that Read Receipts would be coming to Teams. This roll out has been gradual and offers administrative control over the feature, as well as user control via the Teams client.

Microsoft MVP Tom Arbuthnot talks about the control of the Administrive side in his blog here, in this post i'll show you how the user experience looks for a user that has the feature enabled within their Teams client.


Your Teams client should inform you the feature is now available to you. It will be turned on by default so you will immediately benefit from the feature.



If you want to disable it, simply go to 'Settings' | 'Privacy' and you can disable it if you so wish.



If a user you are chatting with hasn't got the feature, even if they see your message your icon will only ever show as 'Sent'. Which is a little dissapointing. You can see in this shot the user has responsed and obviously seen my message but if they hadn't of responded I would have been none the wiser.


However a user that has been enabled for the service will have read receipts working in your favour. You can see from the below screen shots that the message goes from 'Sent', to the eye emoticon that designates 'Seen'.





The feature works well, although I expected it to work and provide receipt clarity on users that aren't using the feature, however I expect it will update and improve over time.


Have fun,






Friday, 2 August 2019

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

Greetings!

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 https://wip.mam.manage.microsoft.com:444 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 https://wip.mam.manage.microsoft.com:444





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,
@OliverMoazzezi




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 'sipfed.online.lync.com' - 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' =  "sipfed.online.lync.com"}}







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 docs.microsoft.com 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.
IntuneWinAppUtil
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!