Friday, September 27, 2019

Azure AD Connect 1.4.x.0 Deletion Threshold Exceeded

Azure AD Connect is configured to perform automatic updates by default. When version 1.4.x.0 (in my case is installed, device objects previously synced to Azure AD might be removed. Previous versions of Azure AD Connect synchronized devices that were not relevant. So, this release is cleaning them up.

For details, see:
In larger organizations, the number of devices deleted might be more than 500 which exceeds the deletion threshold. At this point, Azure AD Connect stops syncing. You might not notice it right away, but any new user accounts will not be synced up to Azure AD/Office 365.

In the Synchronization Service app, you will see a line with the status of:

Before you attempt to fix the issues, you should verify that it is only device objects an not another accidental deletion issue. The steps for this from Microsoft are:

  1. Start Synchronization Service from the Start Menu.
  2. Go to Connectors.
  3. Select the Connector with type Azure Active Directory.
  4. Under Actions to the right, select Search Connector Space.
  5. In the pop-up under Scope, select Disconnected Since and pick a time in the past. Click Search. This page provides a view of all objects about to be deleted. By clicking each item, you can get additional information about the object. You can also click Column Setting to add additional attributes to be visible in the grid.

The fix for this issue is to allow the device deletes to occur by either increasing the threshold or disabling the threshold. You do this on your Azure AD Connect server using PowerShell.

To disable the threshold:
To increase the threshold:
Enable-ADSyncExportDeletionThreshold -DeletionThreshold 1000
To set the threshold back to default:
Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500
 The Microsoft documentation about the deletion threshold is here:


Tuesday, September 17, 2019

Your administrator has blocked this application

I do a lot of work with Powershell and Office 365. To allow for multi-factor authentication when managing Exchange Online, you can use the Microsoft Exchange Online Powershell Module.

I installed the Microsoft Exchange Online Powershell Module on my computer some time back and had used it successfully. However, at some point it stopped working and gives the error:

Your administrator has blocked this application because it potentially poses a security risk. Your security settings do not allow this application to be installed on your computer.

For a while, I've been connecting with normal Powershell for management, but today I wanted to get this thing fixed. This error can apply to ClickOnce applications in general. It is not specific to the Microsoft Exchange Online Powershell Module.

There are trust levels that you can define for ClickOnce applications. These are set in HKLM\Software\Microsoft\.NETFramework\TrustManager\PromptingLevel. There are settings for different security zones. On my system, all of the zones were set to Disabled.

Valid values for these settings are:
  • Disabled. App is never allowed.
  • AuthenticodeRequired. User is prompted to allow app only if the app is digitally signed by using a trusted certificate that identifies the publisher.
  • Enabled. User is prompted to allow app even if not digitally signed.
I have set my zones to AuthenticodeRequired. Any app I'm using should be signed by the publisher and not self-signed. After making the change, I'm prompted to allow the app.

It seems odd that I needed to do this, but I have some Visual Studio components installed on this computer and that might have created the registry keys and set them to disabled.

Microsoft documentation for these registry keys is here:

Saturday, September 14, 2019

SAGE 50 Email Integration Woes

Sage 50 is a pretty common app in Canada for doing small business accounting. However, one of it's major drawbacks is really poor email integration. I think they've improved it somewhat in recent versions, but there is a MAPI dependency.

If you install the 64-bit version of Office, then Sage 50 will not be able to use Outlook to send messages. Now that 64-bit Office is the default for Office 365, you need to watch for that as step one. However, yesterday, on a new install of Sage 50, it wasn't working even with the 32-bit version of Outlook.

We got the error:
Sage 50 cannot communicate with your e-mail program. Please ensure that your email program is MAPI-compatible and that it is the default MAPI client

You also need to have Outlook configured as the default mail program. The Mail program in Windows was configured as the default. So, we changed that to Outlook. Still no luck. Same error.

The final fix for me was adding a registry key. According to a few people in discussion forums, without that key, Sage 50 doesn't load the mapi32.dll that's required to send email. Silly that this is still happening.

In the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Messaging Subsystem, I needed to create a new String Value (Reg_SZ) named MAPI with a value of 1.

Some of the web pages I reviewed during troubleshooting: