Category: Office 365

Azure AD Connect Not Synchronizing to Office 365 – No Errors

Recently we had a very frustrating, yet somewhat easy to fix issue involving Office 365 and Azure Active Directory Connect. Essentially, the synchronization was happening but none of the Active Directory objects were syncing. As a matter of fact, all previous synced users stopped syncing and ended up existing in the cloud only.

When looking at the Office 365 admin portal, there were no synchronization errors shown. Rather, it was showing the synchronization as happening every 30 minutes as usual. When looking at the synchronization service itself, there were no errors shown there either.

Yet distribution groups no longer contained users. New users existed only in Active Directory and not in Office 365.

Many hours were spent talking to Microsoft support over this issue. Installing Azure AD Connect on different servers and different domain controllers gave the same behavior. PowerShell commands did nothing. It was only when I was looking at our other clients AD Connect settings that I discovered that the Source Anchor was wrong.

See, we had been installing Azure AD Connect with express settings. Yet rather than defaulting to ms-ds-consistencyguid for the Source Anchor, express settings set the Source Anchor as domain.onmicrosoft.com – aad. Anyone who knows Azure AD Connect should immediately recognize that this will not work. Even Microsoft says that if the Source Anchor is wrong, there will be no synchronization errors while nothing synchronizes.

So why did the Source Anchor default to something so wrong? Why did it default wrong on different servers? This part remains a mystery.

The fix used to be simple. Even Microsoft’s current documentation explains to use the Azure AD Connect Wizard to change the Source Anchor. However, that is no longer an option with the newer versions of Azure AD Connect.

Microsoft says Configure Source Anchor should be here, but it is not.

In the end, we had to uninstall Azure AD Connect and reinstall it manually (versus the express settings). Once there, we were able to select the correct Source Anchor (ms-ds-consistencyguid) and proceed with the install. Within minutes, all items synchronized properly and as expected.

Go here to change the SourceAnchor

This did not randomly break. Sync had broken two months prior and Microsoft instructed us to reinstall Azure AD Connect using express settings. They had even looked at the installed settings and said it was correct. It was then that we figure the Source Anchor changed its default from the default to domain.onmicrosoft.com -aad instead. After that, it took weeks for anyone to realize anything was wrong (again, as the sync service showed as operating normally and Active Directory changes are few and far between). When we did finally discover this, Microsoft spent many hours troubleshooting on the phone with us and within remote sessions and still didn’t catch that the Source Anchor was wrong.

Proper Source Anchor settings. This was changed to domain.onmicrosoft.com -aad for some reason, causing synchronization to break.

So, there you have it, if your synchronization is ‘working’ but nothing is synching, make sure your Source Anchor did not default to something else other than ms-ds-consistencyguid.

Critical Error when entering Office 365 Exchange

UPDATE: This issue has since been resolved.

We got a ticket today about a user getting a critical error when trying to enter Office 365 Exchange. I recall a similar issue happening to me a week prior, so I took a look. Sure enough, when entering exchange, I get this error:

Here is the full report:

Client Information
——————

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

CPU Class: undefined
Platform: Win32
System Language: undefined
User Language: en-US
CookieEnabled: true

—————–
Exception Details
—————–

Date: Thu Feb 08 2018 09:31:21 GMT-0700 (Mountain Standard Time)
Message: Script error.
Url:
Line: 0

Call Stack
———-

Error

    at Function.ErrorHandling.$Ee (https://r1.res.office365.com/ecp/15.20.464.16/scripts/common.js:1:189941)

    at ErrorHandling.showUnhandledException (https://r1.res.office365.com/ecp/15.20.464.16/scripts/common.js:1:189026)

Dump Event
———-

                isTrusted = true
                message = Script error.
                filename =
                lineno = 0
                colno = 0
                error = null
                NONE = 0
                CAPTURING_PHASE = 1
                AT_TARGET = 2
                BUBBLING_PHASE = 3
                type = error
                target = [object Window]
                currentTarget = [object Window]
                eventPhase = 2
                bubbles = false
                cancelable = true
                defaultPrevented = false
                composed = false
                timeStamp = 7115.5000000144355
                srcElement = [object Window]
                returnValue = true
                cancelBubble = false
                path = [object Window]
                composedPath = function composedPath() { [native code] }
                stopPropagation = function stopPropagation() { [native code] }
                stopImmediatePropagation = function stopImmediatePropagation() { [native code] }
                preventDefault = function preventDefault() { [native code] }
                initEvent = function initEvent() { [native code] }

Detailed Call Stack
———–

This error message occurs across two of three admin accounts on three computers. Oddly, the third account does not suffer this error. It also occurs across at least three browsers – Edge, Internet Explorer 11, and Chrome (Ver 64, both normal and incognito).

As of now, I know of no fix, and several cursory google searches where fruitless. This only started to occur within the past month (as I go into exchange on a monthly basis) and sadly there are no recent posts anywhere about this. If anyone has a clue on how to fix this, or if we simply have to wait until Microsoft does something on their end, let me know. Otherwise we just have to deal with this very minor nuisance.

SMTP Stopped Sending Mail to Office 365

Had a client whose SMTP server suddenly stopped sending scan to e-mails to their domain cloud Office 365 e-mail from their on-premise SMTP server. The queue folder quickly filled up with over a hundred e-mails, so what could have caused this problem?

After three days of troubleshooting, I finally figured it out. In the event log, I was seeing the following issue:

A total of three IP addresses were rejecting the mail, which never even left the queue folder to generate a log in the badmail folder. The three IP addresses were ‘207.46.163.42’, ‘207.46.163.74’, and ‘216.32.180.10’. A cursory search on Google revealed these to be Microsoft servers.

Now this worked perfectly just a few days ago, with no error message like it in the event logs prior to the 23rd of January, 2018. Could it really be this simple of a fix? I tried resetting IIS 6.0, started and stopped the SMTP service many time. I added smtp.office365.com as a smart host, I added a relay as detailed in several websites (including Microsoft’s), and I event played with different settings. Nothing worked… but I did notice occasionally a few e-mails would kick off at a time before failing again as I made changes. Now, I can’t say I know a lot about TLS, but it is my understanding that TLS required authentication and had to go across port 587.

Apparently not. I went back into IIS 6.0 Manager and right clicking on SMTP Virtual server and went to properties. Under the delivery tab, I clicked Outbound Security… at the bottom. There I clicked TLS encryption. I made zero other changes.

I clicked OK and then clicked apply. I didn’t even have to restart the SMTP service – all the e-mail in the queue folder cleared out within moments. Finally, a victory. As a final test, I sent test scans to our domain e-mail account from the Xerox SMTP configuration as well as sending another IT technician to send scans at the printers to themselves. It all worked like it should.

I’m not entirely sure why this works, but I would love if someone could fill me in. Remember, it worked days ago, then suddenly it stopped working until I enabled TLS encryption. I did not configure any ports other than 25.