Congratulations 2020-2021 Microsoft MVP!

I'm very pleased to announce that I have been awarded the Microsoft MVP Award again for 2020-2021 in the Office Apps & Services category! This is my 12th consecutive year to receive this award and it humbles me to work alongside such talented people.

The MVP Award is an important recognition to me and I'm honored to receive it. It includes several benefits, but the most important one to me are all the interactions with the great product groups at Microsoft. These relationships allow me to reach out to specific product team members to provide feedback and get clarification on product features and behaviors.

It's a mutually beneficial partnership -- under NDA, Microsoft is able to talk with MVPs about product futures, provide access to technology adoption programs (TAPs) to test new software, and solicit our MVP feedback. As MVPs, we are able to provide important and honest feedback to the product teams about how new features and behaviors will affect our customers, beta test new software and file bug reports, and be advocates for you, the customer.

As usual, I feel great!

Read more ...

Remove EWS Throttling in Microsoft 365 using Self-Service

A number of third party migration solutions use Exchange Web Services (EWS) for migrations to Microsoft 365. This protocol allows these mailbox migration tools to inject migrated items into the target mailboxes in Exchange Online using delegation or impersonation.

Throttling policies help ensure server reliability and uptime by limiting the amount of server resources that a single user or application can consume in Exchange Online. When high load factors are detected that degrade the performance of these resources, EWS connections are dynamically throttled based on the amount that each caller has contributed to this high load condition.

The result is that the third-party migration tool that uses EWS may be impacted by the EWS throttling policy. Migrations may slow or stop altogether.

See EWS throttling in Exchange for a full description of EWS throttling and limits.

Note: It's important to call out that EWS throttling policies do not affect Exchange hybrid migrations. Hybrid migrations use the RPC over HTTP protocol, not EWS. Do use the steps in this article to try resolving slow hybrid migrations.

Read more ...

Roaming Signatures coming to Outlook for Windows

Read more ...

Significant Improvements in Azure AD Connect

Microsoft just announced that the Azure AD Connect sync V2 endpoint API (public preview) is now available. This new endpoint improves the performance of synchronizations to Azure Active Directory, especially during the exports and imports that happen during sync.

Even though the new V2 endpoint is in public preview, customers can deploy this in their production environments.

For large enterprises, the new endpoint also supports syncing groups with up to 250K members. The previous limit for the V1 endpoint is 50K members. However it's important to know that the new endpoint doesn't have a configured group size limit for Office 365 groups that are written back to Active Directory. For this reason, Microsoft recommends increasing O365 groups incrementally if member size was previously a blocker for your org.

You will need to deploy Azure AD Connect version 1.5.30.0 or later to use the V2 endpoint. Microsoft recommends using a swing migration for deploying the V2 endpoint, where you deploy the V2 endpoint to your staging server, validate it, and then switch over to the staging server. Then you can update your main AAD Connect server to Azure AD Connect version 1.5.30.0. Read the full guidance here.

Switching to the new V2 endpoint is performed via PowerShell.

Set-ADSyncScheduler -SyncCycleEnabled $false
Import-Module 'C:\Program Files\Microsoft Azure AD Sync\Extensions\AADConnector.psm1'
Set-ADSyncAADConnectorExportApiVersion 2
Set-ADSyncAADConnectorImportApiVersion 2
Set-ADSyncScheduler -SyncCycleEnabled $true 

If you have large groups you will need to manually reconfigure the Out to AAD – Group Join sync rule before re-enabling the sync scheduler. See the deployment guidance document for details.

Read more ...

Article - Using Azure AD Application Proxy to Publish Internal Apps

Azure AD Application Proxy allows you easily and securely publish internal web applications to the Internet without modifying your firewalls. It adds another remote access tool to your arsenal.

Read my free article, "USING AZURE ACTIVE DIRECTORY APPLICATION PROXY TO PUBLISH INTERNAL APPS" on the ENow ESE Blog.

I've successfully used this strategy to publish Outlook on the web (OWA) for Exchange Hybrid Modern Auth customers. Let me know how I can help you!

Read more ...

AAD Connect 1.5.29.0 released - With a gotcha

Microsoft released a major update to AAD Connect with build 1.5.18.0 on April 2, 2020. In the last 22 days they've released three newer builds to fix issues in this updated version.

Today they released AAD Connect build 1.5.29.0 which you can download here. But be aware, in my testing Microsoft Defender SmartScreen in the new Chromium Edge browser blocks the download because "this app is not commonly downloaded or is not signed by its publisher".

In order to download it using Edge, click Show More and Keep anyway. This does not happen with the Chrome browser.

I verified that the download is indeed digitally signed with a valid certificate, so I'm not sure why the download is being blocked.

The AAD Connect version release history on this build only lists one unhelpful hint as to what this build fixes:

1.5.29.0

Release status
04/23/2020: Released for download

Fixed issues
This hotfix build fixes an issue introduced in build 1.5.20.0 where a tenant administrator with MFA was not able to enable DSSO.

DSSO is a new acronym to me and I can't find it any any Microsoft documentation, so if you aren't having any trouble with AAD Connect, I suggest skipping this build until the documentation is updated with a better description.

Brian Desmond advised me that DSSO stands for Desktop Single Sign-On - a term I previously only associated with Okta. It's the early name for Seamless Single Sign-On (SSSO).

Read more ...

How to enable (and hack) Cisco AnyConnect VPN through Remote Desktop

If you get the following error when connecting to a Cisco AnyConnect VPN from Windows, it's because the VPN establishment capability in the client profile doesn't allow connections from a remote desktop session.

VPN establishment capability for a remote user is disabled. A VPN connection will not be established.

The client profile is an XML file that gets pushed out to the AnyConnect client every time the VPN is established. The correct way to fix this is by configuring the Citrix VPN profile on the ASA. Usually this is done by the ASA administrator using the Cisco Adaptive Security Device Manager (ASDM). If you're the ASA administrator read this article for instructions how to configure this.

But what if you're not the ASA administrator or the admin can't/won't to make this change for some reason? We can hack it! I don't normally write blog posts like this, but I honestly can't think of a single good reason to block VPN access from a remote desktop, so I don't consider this bypassing a security setting. Here's how to get around it.

First, open the client profile XML file in Notepad. It's located in the C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile folder.

Edit the <WindowsVPNEstablishment> tag to use AllowRemoteUsers instead of LocalUsersOnly.



For example, change:

<WindowsVPNEstablishment>LocalUsersOnly</WindowsVPNEstablishment>

To:

<WindowsVPNEstablishment>AllowRemoteUsers</WindowsVPNEstablishment>

Now save the profile to your Desktop or another location with a .BAK extension. For example, if the original profile name is ContosoVPN.xml, save it as ContosoVPN.bak.

Move the modified .BAK file to the C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile folder. This will normally require admin rights. You should now have two client profile files there, for example ContosoVPN.xml and ContosoVPN.bak.

Now open Event Viewer and navigate to Applications and Services Logs > Cisco AnyConnect Secure Mobility Client. Search for Event ID 3021 from source acvpnui. It should be near the top of the Cisco logs if you just tried to connect to the AnyConnect VPN.



Right-click that event and select Attach Task To This Event. The Create Basic Task Wizard will open.

Click Next.

Click Next again.

Click Next again.

Configure the program to run using the settings below, then click Next.

Program/script:

C:\Windows\System32\cmd.exe

Arguments:

/c cd "C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile" && copy *.bak *.xml /y

This task tells Windows to copy the modified .BAK profile over the .XML file that the AnyConnect client downloads from the ASA whenever acvpnui logs event ID 3021.

Check the box to open the properties for the task when finished and click Finish.

The task properties will open in a new window.

Now test it out. You should be able to connect to the AnyConnect VPN using a remote desktop (RDP).

Be aware that if things change (ports, IPs, etc.) they will be lost/overwritten by the static BAK file. If that happens you can simply delete the BAK file, attempt a connection, and edit the new XML file with the new settings again.

Read more ...