Monday, July 17, 2017

Exchange Managed Availability Spamming the Internet

I ran into an issue at a customer site where Exchange Managed Availability was spamming the Internet with large amounts of outbound to the Internet.  These "Undeliverable: Inbound proxy probe" NDR messages were routing out to the Internet via the Send Connector to inboundproxy@contoso.com - an email address which was intended for internal use within Exchange Environments monitoring purposes.


In the logs we can see the health probe emails are being routed to the Health Mailboxes @domain.local.


These emails are not being delivered and bouncing back to the sender “inboundproxy@contoso.com” which of course “@contoso.com” is not an Accepted Domain in your Exchange environment so it is routed out to the internet for delivery.

The Health Mailboxes (part of Microsoft Exchange Managed Availability) all reside under the Monitoring Mailboxes location.


These mailboxes are automatically created by the "Microsoft Exchange Health Manager" service, if any of these mailboxes get deleted, the service will recreate them upon restart.

All these health mailboxes have a have the external SMTP address configured and a domain.local SIP address.

SIP, not SMTP.  Hence delivery fails.


Managed Availability automatically routes to the FQDN of whatever the forest root domain is for the Health Mailboxes and as a result, this SMTP address must exist on the Health Mailboxes.

I created a PowerShell script to return all health mailboxes which do not have a SMTP address matching alias@domain.local and then add the missing email.

Get-Mailbox -Monitoring | %{ if(!($_.EmailAddresses -contains "smtp:$($_.Alias)@domain.local")) { Write-Host "Adding email address  for $($_.Alias)"; Set-Mailbox $_.Alias -EmailAddresses @{add="$($_.Alias)@domain.local"} } }


We can validate the @domain.local is now on all Health Mailboxes.


The reason why these domain.local addresses were not on the Health Mailboxes was someone removed @domain.local from the default Email Address Policy in the customers environment.

I hope this post was helpful. 

Software no longer displaying in Software Center - SCCM 1702

I had an issue at a customer where software was no longer appearing in Software Center on the workstations.  Please note - this screenshot was taken after I fixed the issue.


After much troubleshooting, I was able to fix the issue.

For each application not appearing, I needed to do an "Update Content" in SCCM.


To force the SCCM client to update the application after the content was updated, in the Configuration Manager client, under Machine Policy Retrieval & Evaluation click Run Now.


Monitor the C:\Windows\CCM\Logs\AppDiscovery.log on the client and you should see the application which you ran the Update Content for appear in the log file.

 
When the application appears, close and re-open Software Center, you will see the application present.
 
I'm not sure what actions lead up to the many of the applications disappearing in Software Center, however these actions resolved the issue. 

Forcing Azure AD Connect to Sync

The new Azure AD Connect Tool was released in April 2017 to replace the legacy DirSync utility for maintaining Identity Management with Office 365.

This new tool syncs much more frequently then the legacy DirSync tool - every 30 minutes by default to be exact.

However when creating a new on-premises user, there may be times where you want to instantly synchronize the user to Azure Active Directory.

This can be done with PowerShell on the new tool with the following cmdlet:

Start-ADSyncSyncCycle -PolicyType Delta

 
I hope this post has been helpful.
 

Wednesday, July 12, 2017

.NET Framework 4.7 and Exchange Servers

.NET Framework 4.7 is currently not supported on Microsoft Exchange Servers. This is heavily documented on the Internet with many articles such as the one below:

https://supertekboy.com/2017/06/17/dont-install-net-framework-4-7-on-exchange/

However Windows Update automatically installs .NET Framework 4.7 now on servers and many of my customers have been caught out by accidently installing this latest framework update on Exchange Servers unknowingly by simply installing the latest patches.

To ensure you don't get caught out, it is recommended to put the following registry key on your Exchange Servers to block the installation of .NET Framework 4.7 on Exchange servers.

  1. Tap on the Windows-key, type regedit.exe, and hit the Enter-key on the keyboard. This should start the Windows Registry Editor.
  2. Go to the key: HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP
  3. Right-click on NDP and select New > Key.
  4. Name that key WU.
  5. Right-click on WU, and select New > Dword (32-bit) Value.
  6. Name it BlockNetFramework47.
  7. Set its value to 1 (double-click it to set value).