Outlook 2016 & AD Directory Servers

[dstranathan]

We are upgrading our AD domain. We are adding new DCs and phasing-out older DCs in our domain. We are not migrating domains, we are simply raising the domain functioning level with newer versions of Windows Server 2012 R2.

Outlook 2016 (and presumably Outlook 2011) seem to set their LDAP GAL Directory server one time (at account set up time or initial launch). After discovering a DC with the GAL, it appears that Outlook never tries to query for GAL servers again. I assume it does this by searching for _ldap._tcp.sgc.loc SVR records in DNS or it does it via AD CAS AutoDiscover foo that Im unaware of.

Im concerned that once my old DCs are phased-out that my Outlook users will no longer be able to do GAL lookups from AD because Outlook will be pointing to stale/deprecated servers.

Can anyone confirm what Outlook does when can't find a Directory Server? Will it try and discover new servers?

Can Outlook's Directory Servers be configured via a script or cli command? I can't find were the Directory data lives (I assume its baked-into a database blob and not a text file or xml .plist). Outlook does not use OS X Directory Services stack

Im referring to the Outlook setting located here Outlook > Preferences > Accounts > Advanced > Directory server > Server/Port

Im going to open a ticket with Microsoft if needed, but I thought Id run it past the JAMF community first.

[jonnydford]

While this isn't exactly what you're looking for, this should be a good read for you:

http://blogs.technet.com/b/neiljohn/archive/2012/03/23/forcing-a-full-oab-download-in-outlook-2011.aspx

[dstranathan]

I have seen that MS TechNet document, thank you @jonnydford. It covers only Outlook 2011 (which may have the same behavior as Outlook 2016, but the data caches certainly live in different locations)

I tried to flush caches what I think is the correct location for Outlook 2016:

~/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/com.microsoft.Outlook/

However, Im not sure if this where the GAL directory settings live. Just a hunch.

Maybe @talkingmoose can chime-in?

[hisaac]

I'm looking for a solution to the same issue. When contact info gets changed in our AD/O365, the Mac Outlook's contact list doesn't update. Very frustrating.

I tried flushing caches in both:
- ~/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/com.microsoft.Outlook/
- ~/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/com.microsoft.Office365ServiceV2/

But neither fixed the issue. Help us @talkingmoose, you're our only hope!

[hisaac]

@dstranathan I think I'm getting closer to an answer.

Through this post, I found what looks to be the Offline Address Book .plist file here: /Users/isaachalvorson/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/Main Profile/Caches/1

I tried quitting Outlook, and deleting the OABQueryInfo.plist file as advised in that article. After reopening Outlook, the GAL was gone from the address book, so I was hopeful. It then re-appeared, but still contains the out of date info! Not really sure what's going on there. I would think if it cached the GAL, it would download the most recent information.

[talkingmoose]

Hi folks! This one may be a little tricky. For the most part, Outlook 2011 and 2016 behave the same way with regard to the Offline Address Book (OAB). I can think of a few things that may help you.

• Newer versions of Exchange may have changed this, but I don't think so: Your Exchange server will only generate a new OAB for clients to download once per day (usually early morning).
• Outlook does not constantly sync the OAB file from the server. Instead, it only syncs once every 24 hours.
• If you change anything in Active Directory, make sure that change synchronizes to all your domain controllers first before checking Outlook.
• Make sure you've got a current Global Catalog server (specific type of domain controller) specified in Outlook's Exchange settings under Outlook menu > Preferences > Accounts > your Exchange account > Advanced > Directory Service.

Next, it's possible to use AppleScript to determine what you're using as your GAL. This should be where you're getting the OAB:

tell application "Microsoft Outlook"
    get gal download directory of exchange account 1
end tell

I'm using Office 365, so I can only show you what I get from that (below). I expect it's a bit more understandable with an on-prem Exchange server. If you enter that URL in a browser, you should be prompted for your Exchange credentials. If you can log in then you're connecting correctly. You won't necessarily download or see anything by doing this, though.

"https://outlook.office365.com/OAB/2d1f6b5f-c74d-4803-b7f4-fbbda4ee8c30/"

Finally, you can trigger an OAB download using AppleScript too:

tell application "Microsoft Outlook"
    download oab now
end tell

I confirm this path on my system is where my OAB updates seem to go. Even if I force a sync, I don't necessarily see the time stamps update. This might be another place for you to look:

'~/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/Main Profile/Caches/1/Download/'

[dstranathan]

I just closed a ticket with Microsoft regarding LDAP Directory Services, the GAL and Outlook 2016. Here is a run down on what the (2) MS engineers told me:

-Don't change anything manually.
-Outlook will dynamically pick up the new AD/Exchange infrastructure changes.

So I did nothing. I should get a raise for all this hard work.

I was very skeptical of the MS information at first. They actually escalated the ticket twice, thus I got fairly high up in rank I think. They seemed confident.

We recently shut down the legacy DCs I mentioned in my original post, and brought the new DCs online as planned. The migration took a few weeks. We did it nice 'n slow to make sure the new servers were functioning before we yanked the old servers. We were in no hurry.

So far everything is fine. Im able to find newly-hired members in Outlook 2016 via the Exchange GAL that didnt exist befre the old servers were decomissioned. No issues or complaints from users.

There you have it. In my situation Outlook 2016 is automagical. Your mileage may vary.

[bryan_feuling]

@talkingmoose

I've been using your script for our Outlook automation (with a few tweaks here and there). One issue that we have been having is that our GAL and OAB is not downloading properly when using the script. However, when we manually add our Exchange Accounts in Outlook, the GAL and OAB work perfectly.

I've tried the GAL and OAB download scripts you have above, and I'm not getting anything from that.

Any thoughts?

[talkingmoose]

@bryan.feuling, the problem is probably the script has a bug that I haven't fixed with the Autodiscover setting.

This property setting is really true:

property disableAutodiscover : false

And this one is really false:

property disableAutodiscover : true

The OAB relies on Autodiscover being enabled. Flip this around and see what happens.

[bryan_feuling]

@talkingmoose

It seems as though this is working. However, when turning on Auto Discover, we are finding that users are being prompted with a log in message box every time the close and open Outlook. We currently use a main server that does not have Kerberos, but our beta server (Which will be eventually moved to) is kerberos enabled. Does the fact that the main server is not kerberized have an effect on these repeated login prompts?

Also, you show the OAB url in a few comments above. The key at the end of the URL ("2d1f6b5f-c74d-4803-b7f4-fbbda4ee8c30"), do you know if that key exists in your "UBF8T346G9.Office" location that might be able to be passed to the "gal download directory"?

[talkingmoose]

@bryan.feuling, a login message box? What version of Office 2016 are you installing? Older versions had an issue where the Keychain entries were causing problems prompting users to log in at every launch. @pbowden with Microsoft created a tool to deal with this.

https://github.com/pbowden-msft/NukeOffKeychain

Kerberos and Autodiscover are unrelated. Kerberos helps authenticate users to their server and Autodiscover helps Outlook find its servers. Autodiscover does not require authentication, but it may point Outlook to a server service (such as the Offline Address Book) that will require authentication.

The URL I posted was an example of the response you'd receive in the AppleScript Script Editor when running the three-line script above it. I have no idea what significance the string of characters at the end of the URL plays other than it appears to be a unique identifier for the specific version of the OAB at that moment in time. It will change on a regular basis (probably as items are added or deleted in the OAB).