SPEAKING AT CLOUD8 – VIRTUAL SUMMIT

I’m excited to be chosen as a speaker at the Cloud8 virtual summit (Part II). Cloud8 2020 is again held all virtual, on November 13th. The event is an IT community conference focused on Microsoft cloud, datacenter, security and modern workplace topic, with Microsoft MVPs, Microsoft Regional Directors and other industry experts. Check out the event website.

MY SESSION

I will speak about Zero Trust, protecting your identities and implementing Identity Governance. My session title and speaking slot:

Identity Governance – A valid and secured Identity is gold!
– Session 17, 3PM –
Use this link to go to the whole session catalog: LINK

SOME WORDS ABOUT Cloud8

Cloud8 is all virtual, as mentioned above. This year, it is the second time that Cloud8 will be held and that’s why is called part II :-).

Community leader Drago Petrovic started in spring with this great event and first edition. If you are interested in Microsoft cloud topics, this is a must event. You can join all sessions using Microsoft Teams and as it is a real community event, it’s free. However, it needs a lot of working hours to raise an event like that. So, thanks a lot to the organizers!

HUB Zone
There ist a HUB Zone where you can meet others. In the HUB Zone you have the possibility to exchange and connect with other visitors and speakers of this event. Use this platform as a virtual meeting zone and who knows… Possibly new synergies will arise. It’s easy to join as well, just klick on the “join HUB meeting link”. Would be cool to see you there, virtual!

Official hahstag used: #cloud8

We just had our briefing call with Drago:

So do not miss to check out the great speakers line-up.
See you there!

SPEAKING AT EXPERTS LIVE SWITZERLAND 2020

I’m excited to be chosen again as a speaker at Experts Live Switzerland . Experts Live Switzerland 2020 will take place on September 30 at “Welle 7” in Bern Switzerland. Experts Live Switzerland is an IT community conference focused on Microsoft cloud, datacenter, security and modern workplace topic, with Microsoft MVPs, speakers from Microsoft and other industry experts.

MY SESSION

I will speak about Zero Trust, protecting your identities and implementing Identity Governance. My session title and speaking slot:

Identity Governance – A valid and secured Identity is gold!
– Track 3, 3PM –
Find the all sessions here.

Experts Live Switzerland will be the first in-person event for me since more than 6 month, all pretty well organized with all the COVID-19 rules & regulations.

SOEME WORDS ABOUT EXPERTS LIVE

The first time this year since #ELCH all sessions are being presented in english.

Experts Live Switzerland 2020 is limited to only 150 attendees. There will be a lot of other great sessions and a lot of experts from the Microsoft Cloud community across Europe. One of the main advantages of joining the Experts Live events is that you get this great networking opportunity to learn from each other.

Check out the Experts Live Switzerland website for more detailed information’s. Would be cool to see you there!

PIN RESET NOT WORKING ON AZURE AD JOINED DEVICES

You may get this error when you try to reset the PIN of your Azure AD Joined Device:

CAA2000B. AADSTS500014: The service principal for resource cred.microsoft.com is disabled. This indicates that a subscription within the tenant has lapsed, or that the administrator for the tenant has disabled the application, preventing tokens from being issued for it.”

Based on that, you will recognize that an Admin had to setup the PIN Reset feature for your tenant and provide consent to the app. A detailed instruction to onboard it to your Azure Active Directory Tenant can be found on this docs article here.

This setup deploys two OAuth apps to your Enterprise Applications in Azure called Microsoft Pin Reset Client Production and Microsoft Pin Reset Service Production.

On the properties page of the Pin Reset Service Production, the Application was disabled in my case. But even after enabling the OAuth application, it still did not work to resetting the PIN on an Azure AD Joined device. We received the same error above.

In this case, make sure that the Security or Global Admin did not block the OAuth App within Cloud App Security. You can verify the blocked app by navigating to your Cloud App Security portal by:
https://tenantname(without .onmicrosoft.com).portal.cloudappsecurity.com / Investigate / OAuth apps and search for “Microsoft Pin Reset“. This will show you the both apps you also have in Azure Active Directory Enterprise Applications.

In case one app is blocked, click on the red block sign an unblock the app to get a green tick :-). If one is blocked, users won’t be able to reset their PIN. This was the case here.

After that, I had to give consent to the Microsoft Pin Reset Client Production app again using the Enterprise Application Permission blade and an account with sufficient rights to grant consent.

SOME OTHER THOUGHTS
Some other features such as Self-Service-Password-Reset (SSPR) and the combined registration for security information’s is recommended (Users can use the combined security information registration experience). Consider also Azure AD Connect to use Password Hash Sync and Password Hash Writeback in Hybrid Identity deployments. Hope this helps.

Happy PIN Reset!

SPEAKING @ “REMOTE Cloud Workplace Meetup #6”

The “REMOTE Cloud Workplace Meetup” Number 6 will be held on June 9th. As COVID-19 still blocks us to meet in person, this event will be a virtual event with two sessions. I’m very happy to serve the first session.

WHAT IS THE CONTENT

We will talk about Identity and Access Management. As this is only a 35 minutes slot, incl. Q&A, I will only cover thre topics:
– Zero Trust (very short)
– Azure Multifactor Authentication based on Conditional Access
– Access Reviews for Teams or Microsoft 365 groups (Former Office 365 groups)
Feel free to register here: Remote Cloud Workplace Meetup #6

SESSION OUTLINE

A valid and secured Identity is gold!

Azure Active Directory (Azure AD) brings you several options to achieve this goal.

First of all you should enable Azure MFA for all users. But hey: What about all the Admin Accounts and what in case of Azure MFA fails. We will show how to enable Azure MFA in a right way and make sure you have a protected identity.

What else: Using Identity Governance and Access reviews you have a tool on board which helps you to review access to your Office platform such as Microsoft Teams.

Hope to see you there!

REMOVE ADFS FARM AFTER MOVING TO AZURE AD AS IDP

Currently and in the past I have done a number of ADFS to Azure AD authentication projects, where authentication is moved to Password Hash Sync (PHS) & Seamless SSO or Pass Through Authentication (PTA) including sSSO.

First of all you should know your environment when starting removing services. I assume, that you’re aware of the server that are joined to your ADFS farm. If not, STOP here and start over :-). No, you can use PowerShell to get a list of your servers and specially the primary server of your farm. Run that on one of your ADFS hosts:

Get-ADFSSyncProperties

Make sure you have migrated all authentications to Azure and you have disbled the relying party trusts for a while now. This gives you the certainty that no authentication flow still passed your ADFS environment.

You should also consider the “Application” logs on each of your ADFS server. Filter them by using “AD FS, AD FS Auditing, AD FS Tracing and ADHealth-Adfs” to confirm no auth-flow runs over ADFS.

If you still see failing authentications going over your farm, make sure they get migrated to Azure before you remove your ADFS servers. Also have a look into the Application and Services Log/ADFS/Admin. If all is clear, you can start decommissioning your farm.

On your primary ADFS server check the certificate sharing containers as you will need that later to remove it within ADSI. Do that before you removing the ADFS farm.

(Get-ADFSProperties).CertificateSharingContainer

Remove the WAP Servers

Login to each WAP server, open the Remote Access Management Console and look for published web applications. Remove any to ADFS related that are not being used any more. Make a note of the URL that you are removing – its very likely that this means you can remove the same name from public and private DNS as well once the service is no longer needed. You can accomplish this by using PowerShell:

Remove-WindowsFeature Web-Application-Proxy,RSAT-RemoteAccess

If you need an alternate solution for Remote Access Management and WAP, have a look into Azure Application Proxy

Remove ADFS Server

On your second host start PowerShell and remove the ADFS Trust incl. the Windows Internal Database Feature (If not needed for other stuff). Run the command and reboot the server:

Remove-WindowsFeature ADFS-Federation,Windows-Internal-Database

Also remove the ADFS database on the local system by running the command bellow. This will clear the folder with the ADFS database and logs.

del C:\Windows\WID\data\adfs*

Clean-up some more ADFS Stuff

Do not forget to remove:
– Internal and external ADFS specific DNS records
– Load Balancer configurations for ADFS Farm
– Firewall rules between Internet, Load Balancer, DMZ and ADFS Servers
– Revoke certificates if no longer needed
– Service accounts, Group Managed Service Accounts
– Remove IIS on the ADFS Server and/or decommissioning the Windows Server itself

If you have removed all ADFS Servers from your forest, you are now save to remove the ADSI entries under for the Certificate Sharing Container within ADSI edit: CN=Microsoft,CN=Program Data,DC=domain,DC=local

All done. Hope this helps!

MIGRATE AZURE AD CONNECT TO ANOTHER SERVER – CONSIDER “SOURCE ANCHOR”

Sometimes it’s required to migrate your Azure AD Connect to a new OS or another server. This is actually a straight forward thing and you can find severeal blogs to do that – just google it. But one thing you should keep in mind is the SourceAnchor immutable attribute. Immutable means “not changeable”.

Since this attribute’s value cannot be changed after it has been set, it is important to pick a design that supports your scenario. Consider this, check the docs site for more information.

The change to another server requires Azure AD connect to be installed in staging mode. Staging mode enables you a “Hot standby” Azure AD Connect server and allows you to migrate from the original server to the new one or in case of a server failure to switch over.

During the installtion of the staging server, Azure AD Connect wizard checks the SourceAnchor attribute. Since version 1.1.524.0 of AADC, the attribute ms-DS-ConsistencyGuid is used as the primary source anchor instead of the objectGUID attribute. AADC checks the ms-DS-ConsistencyGuid within the forest and in case the attribute is not used by any service, an automatic migration will take place.

Now when you move to a new server, Azure AD Connect will drop an error, that the attribute ms-DS-ConsistencyGuid has already values and instead objectGUID will be used as the source anchor. If you ignore this, you will run in trouble for sure! So be careful.

SOLUTION
If you are certain that the attribute isn’t used by other existing applications, you can suppress the error by restarting the Azure AD Connect wizard with the /SkipLdapSearch switch specified. 

"c:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe" /SkipLdapSearch

SkipLdapSearch allows you to change the staging mode server to the sourceAnchor attribute ms-DS-ConsistencyGuid.

Make sure all your settings are identically configured on the staging server compared to the source server before you switch to the new installed box.

Happy sourceAnchor-ing!

AUTOENROLLMENT FAILS WITH UNKNOWN ERROR 0x80180001 & 0x8018002a

Recently a customer called, that the Automatic Enrollment for MDM is not working as excepted and the clients are getting some errors during MDM Autoenrollment. Easy I thought, let’s have a look…

Within the Eventlog under Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider the error Unknown Win32 Error code: 0x80180001 was triggerd.

Usually you configure MDM Automatic enrollment using a GPO after your devices are Hybrid Joined (to do so, check that post here).

Since Windows 10 1903 this GPO policy got a change. You can now select Device or User Authentication. If you select Device Authentication, a device token will be used to enroll the device, but this is not supported for Intune, based on this Docs article.

Also, another error caused in the Eventlog which indicates, that the GPO setting must be misconfigured:

MDM Enroll: Server Returned Fault/Code/Subcode/Value=(MessageFormat) Fault/Reason/Text=(Device based token is not supported for enrollment type OnPremiseGroupPolicyCoManaged 

As soon this GPO policy is applied to a device, a scheduled task is created and triggers the enrollment process every 5 minutes.

You can find this task under \Microsoft\Windows\EnterpriseMgmt. If you check the arguments for this specific task, you probably realize that the argument uses the string:

/c /AutoEnrollMDMUsingAADDeviceCredential

So, still device authentication is used. This causes our error. Let’s change that to User authentication.

To test the enrollment with user auth, you can ether changing the GPO to user authentication (this did not change the scheduled task arguments in my case, even after reboots, gpupdate, etc.) or just manually changing the string to:

/c /AutoEnrollMDMUsingAADUserCredential

After that, the devices started to auto enroll into Intune. Be aware, that auto enrollment, enrollment restriction and Azure AD device registration needs to be enabled and configured for that.

Your users will receive a toast message that some account settings has been changed.

If you use Azure MFA maybe another error will popup in the event log but not displayed to the enduser:

Auto MDM Enroll: Failed (Unknown Win32 Error code: 0x8018002a)

This will also block the enrollment process. You can avoid that, by configuring an exclusion in Conditional Access for the “Microsoft Intune Enrollment” cloud app.

Hope this helps!

DISABLE EXTERNAL SHARING FOR A SPECIFIC TEAMS

If you use Microsoft Teams, then is external sharing one of the option you probably love. You can share a whole Team with your Co-workers like customers or partners.

But in some cases you would like to disallow external sharing for a specific Teams. Maybe to protect accidental sharing of sensitive information located in a specific channel – Data under NDA, Management, HR and so on. Of course you would use AIP/Senitivity labels to protect your data, but here we will block the Teams external sharing option.

The easiest way to achieve this, is using PowerShell. First of all you need to install the Microsoft Exchange Online PowerShell Modules. To do so, login to your Exchange Online Portal by browsing to https://outlook.office365.com/ecp/ Hybrid – and click configure to download the Application.

Install the application and launch Microsoft Exchange Online PowerShell Module from your Windows Start Menu. Follow the next view steps to block external sharing in your Teams:

STEP 1: CONNECT EXCHANGE ONLINE

Use Exchange Online Modules
Set a Groups/Teams to 'AllowToAddGuests' == $False
Connect-EXOPSSession -UserPrincipalName 

STEP 2: GET TEAMS GUID

Get-UnifiedGroup
#If you have many Teams, you can select the Teams by name
Get-UnifiedGroup | select "<name of your Teams>"

STEP 3: WRITE TO VARIABLE
Write the ExternalDirectoryObjectId property to an variable.

$group = Get-UnifiedGroup -Identity "<GUID of your Teams>" | select "external" -ExpandProperty ExternalDirectoryObjectId

STEP 4: ADD THE AZURE AD TEMPLATE TO VARIABLE
The Get-AzureADDirectorySettingTemplate cmdlet gets a directory setting template from Azure Active Directory (AD). We need the group.unified.guest for our goal and adding the settings also to variables.

$template = Get-AzureADDirectorySettingTemplate | ? {$_.displayname -eq "group.unified.guest"}
$settingsCopy = $template.CreateDirectorySetting()
$settingsCopy["AllowToAddGuests"]=$False 

STEP 5: FIRE THE COMMAND
Now we need to fire the command against our Teams.

New-AzureADObjectSetting -TargetType Groups -TargetObjectId $group -DirectorySetting $settingsCopy

RESULT: NO EXTERNAL SHARING POSSIBLE
Within the specific Teams, you wont be able anymore to add guest accounts (even if they are already enrolled in your AzureAD) or share with people outside of your organization. In the picture bellow, I tried to add an external account to the Teams:

Maybe this helps. Let me know if you have any suggestions on this!

EDIT GROUP TAG AND COMPUTER NAME IN WINDOWS AUTOPILOT

Since a while we’re waiting for this change in Windows Autopilot. We can now edit and change the Group Tag and Computer Name filed within the UI or trough PowerShell. This is part of the Intune release 1911 (November 2019).

Open the Device management portal: devicemanagement.microsoft.com
Navigate to Devices – Device enrollment – Windows enrollment – Devices and select the device you like to rename. The option blade now allows you to change both entries, Device Name and Group Tag.

This is very useful for doing changes on the device or assign a different Autopilot profile. If you use dynamic groups, the device will automatically be reassigned to the new Profile as long you have a dynamic group which is queering the new Group Tag.

Also, a new PowerShell module was published by Michael Niehaus to edit and change those values. Make sure you upgrade to the latest version (at least version 3.9).

Update-Module -Name WindowsAutoPilotIntune -RequiredVersion 3.9

Use Set-AutoPilotDevice to rename the device or change the Group Tag after you have connected to MS Graph using Connect-MSGraph. Here is an example of the command:

Set-AutoPilotDevice -id 8afc147f-8893-441b-a47d-3c0f3652c1a4 -groupTag "PartnerCtrRegistered-AP" -ComputerName MasterWayne

Force a sync of the Autopilot service to see the changes or wait until the service has synced. You’re all set now. Enjoy!

MY UPCOMING SPEAKING ENGAGEMENT

It is going to be a busy time until the end of November!
I’m very proud to be a part of some great conferences and user groups to present about Modern Workplace stuff like Modern Device Management and Microsoft 365 Governance.

AZURE USER GROUP ZURICH
Already next week you can join me at the Azure User Group in Zurich. There is a full track about Digital Cloud Workplace and how to move from a “legacy” management to a modern cloud (enabled) management or better I say, to a Modern Workplace! Of course, using tools from the Microsoft 365 products. If you like to join check out the agenda and register now for the MeetUp in Zurich:

Tuesday, October 29, 2019
Digital Cloud Workplace at Azure Zurich User Group

EXPERTS LIVE EUROPE
I am happy to let you know that I will be speaking at Experts Live Europe 2019 in Prague. The conference will be held in from November 20-22 2019. This is huge for me and I’m very happy to be a part of this conference, specially as a speaker in this year. If you’re interested to join, you can find more details about the conference here:

Wednesday – Friday, November 20-22, 2019
Experts Live Europe 2019, Prague
My session – 10:30, Club E!

GEEKMANIA
Also in November, at the 29th, we will be at a community event called Geekmania in Zurich, Switzerland. This event covers two tracks, one for Azure and another one for Microsoft 365. I’m happy to provide two sessions in the afternoon.
In the first session I will show, why and how you can use Microsoft 365 and in the second session we will talk about Modern Device Management. Would be cool to see you there and if you have, bring some questions!

Friday, November 29, 2019
geekmania 2019, Zurich, Switzerland

#COMMUNITYPOWER

SPEAKING ENGEMENT