Outlook 2016 autoconfigure

[hkabik]

Now that the schedules tab is removed from Outlook's preferences... has anyone figure out a way to apply a self configuration script like this one?

https://github.com/talkingmoose/Outlook-Exchange-Setup

Our users really enjoyed everything being automagically configured.

[alexyu650]

@talkingmoose Hey, I am trying to use your Pacakge for Deployment.app and it keeps erroring out. I have tried following the directions for your terminal workaround which I found on the wiki and have gotten the same issue. I also tried the work around by running it in script editor. It keeps giving me the "Package build failed. Verify ROOT and Scripts folders are in the same folder as this Package for Deployment app." message. Any idea on whats going on? I am trying to build this on a Sierra 10.12.6 mac. Any help is appreciated! Thanks!

[talkingmoose]

@alexyu650, if you've already tried running from within the Script Editor, try copying the entire contents of that script to another Script Editor window and run it there. Apple has done some hardening, which makes the packaging app/script difficult for people to use.

However, the Terminal commands should work just fine. That's all the script is running.

[boonkeatgan]

@talkingmoose Thank you for the link. A quick question on the outlook kerboros setting. When i choose useKerboros=true, it will not choose the kerbors i have (please see attached). Instead of it create it own localcacheuser@domain file. How can we define this during deployments?

[talkingmoose]

@boonkeatgan, the Kerberos setting assumes you're logging in with an Active Directory account. Then, the script reads the Active Directory user of the current user to determine the Kerberos user string.

I just want to make sure you're testing with an Active Directory account when you see this.

Next, I recently worked with someone who's Active Directory information that's returned during a lookup differed in structure from my Active Directory test instance. I proposed the following change to the script. See if it helps you as well:

Locate this section:

set AppleScript's text item delimiters to {";Kerberosv5;;", ";"}

try
      set userKerberosRealm to text item 2 of userInformation
end try

set AppleScript's text item delimiters to {""}

And replace it with this:

set AppleScript's text item delimiters to {";Kerberosv5;;", ";"}
repeat with aParagraph from 1 to count of paragraphs of userInformation
      if paragraph aParagraph of userInformation contains "Kerberosv5" then
            try
                  set userKerberosRealm to text item 2 of paragraph aParagraph of userInformation
                  exit repeat
            end try
      end if
end repeat
set AppleScript's text item delimiters to {""}

[boonkeatgan]

@talkingmoose Wow, you are genius mate! After changed the script and it is worked like charm.

Right now only outstanding item is the Welcome to Outlook prompt and I need to completely exit MS Outlook then relaunch again before the script is able to work.

I tried to use the mobileconfig provided, if the "Setup your email" screen does not pop up. The script wont work.

[talkingmoose]

@boonkeatgan, I really appreciate you testing that second script snippet so quickly! I'll eventually work to incorporate that change in the script, now that I have a second confirmation it works.

The screen offering to configure an Outlook account is only presented for Office 365 accounts. Line 52 of this very comprehensive list of plist keys/values for Outlook is the solution.

https://goo.gl/UC04oZ

Create a plist file similar to this and upload it to a Custom Settings payload in a new Configuration Profile:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>OverrideAccountConfigurationWindow</key>
    <true/>
</dict>
</plist>

As for having to restart Outlook when setting to use Kerberos, I've heard this a few times. By the time it's configured, the script is finished running. This is just the behavior of Outlook. I don't know of anything to begin the sync without restarting.

[boonkeatgan]

@talkingmoose Thank you for the quick reply. I tested that configuration profile before. Once this config profile is installed, the auto script wont work at all. No matter how many times you restarted the outlook.

I still have not find any clue on this.

[talkingmoose]

@boonkeatgan, be sure to always test under a clean user account. I suggest using a VM with snapshots to help you roll back to a state before Outlook's first launch.

Also, are you leaving the configuration profile that accompanies the script in the package and deploying it to? Or are you deploying that profile using Jamf? Either method should work. It just needs to be there before Outlook runs the first time.

[boonkeatgan]

@talkingmoose Merry Xmas to you mate.

I was away and just happen to see your reply. Sorry for late response.

Yes, I always re-image on MacBook Pro when doing the testing. For the configuration profiles, i deployed during imaging. So, it should be there before user click on Outlook.

I cannot deploy the config profile thru push down because we are using Bluecoat Proxy. If we want to deploy the config profile, we will extract and put it as policies instead.

[tim_rees]

Never mind.. I'm an idiot!

[talkingmoose]

https://twitter.com/meck/status/955640670609428480

[mvught]

@talkingmoose

Hello Moose,

I really like this idea, do you think it will coming soon? I have a problem with my accounts at the moment, we are switched from AD to Local accounts (NoMAD) and now we want to configure the email locally but its not working anymore.
I have adjusted everything but maybe I see something wrong?

Your return output is the same as mine, so that will be ok.

I wrote the script for environments where Autodiscover wasn't available. At the time I was using it, I was educating my Exchange folks about Autodiscover, but they were pretty slow to enable it. Outlook's AppleScript dictionary does support calling Autodiscover:

tell application "Microsoft Outlook"
    autodiscover email address "bill@talkingmoose.net" user name "bill@talkingmoose.net"
end tell

It returns something like:

true, server:"https://outlook.office365.com/EWS/Exchange.asmx",
primary smtp address:"bill@talkingmoose.net",
oab manifest url:"https://outlook.office365.com/OAB/2d1f6b5f-c74d-0000-b7f4-fbbda4ee8c30/",
port:443, full name:"William M. Smith", ldap server

I've just never considered modifying the script to support Autodiscover if it already works. It would take a bit of work to redo the script to support Autodiscover (maybe version 6.0?), but if you're familiar with how to take the output above and slip it into the properties at the top of the script, then that should be all you need.

thanks for your good tool!

[talkingmoose]

Hi @mvught! I responded to your message on Slack. Had a couple questions for you there.

[Malcolm]

@talkingmoose are you able to confirm this is working for Mojave?

if I run the package rather than as a deployed package it comes up saying it is incompatible with this version.

after editing the script, and running the script from script editor it did appear to complete the script install. but the pkg not as successful.

But it could be a user error on my end in compiling the .pkg
So if you can confirm it runs on Mojave I can look at where I went wrong.

[Malcolm]

Further investigation found that it was due to it being run previously on the device.

It's now working for the most part for me on Mojave.

What is occurring however is:
each signed on user gets prompted by the first use splash screen (I think there was mention of a solution to this further up int he thread so I will investigate).

our office365 still requires auth which cant be over come it seems, especially as we auth via azuread instead of adfs.

and the OSAscript wants the authority to run with each user instance when outlook is first opened.
Would this be a permissions issue that I can overcome? Or does the pkg need to be signed with a code signing cert? As I have one if it would solve the problem?

[talkingmoose]

@Malcolm, just now seeing this. Thanks for your diligence in troubleshooting.

I haven't yet tested the scripts on Mojave, but I suspect you're seeing what I was afraid would happen. I'm thinking Mojave's new Privacy Protections feature may be getting invoked. While Jamf does have the ability to send a configuration profile to Macs to eliminate these prompts, scripts require a little extra attention and signing.

I need to investigate this and see what can be done.

In the meantime, Microsoft has enabled both Office 365 activation and Outlook configuration using configuration profiles. This is all new as of the latest release of Office 2019 v16.18 and was demonstrated at this year's JNUC. I've already composed a blog post but I'm waiting for the video to release before publishing.

Are you using a directory service such as Active Directory or LDAP to populate email addresses into the computer records in Jamf Pro?

[Malcolm]

@talkingmoose yeah I noticed your profiles to remove the first use, so got that sorted.
we do use ldap, I will have to try and get an updated copy of the volume license deployment of office 365 mac. Our government department that we work under dont provide us to rights to access this from microsoft directly. I will give a try using the package provided through our office 365 instance, but I dont know if it will work.

From my investigations, the automation section of system preferences > security and privacy needs to trust the script.

but I am not sure if jamf can be used to force approve it?
looking in config profiles I couldn't find such option.

I was going to investigate using composer to see what gets modified through the approval process, to see if theres a way of doing it that way.

[ateazzie]

I used Talkingmooses script to autoconfigure outlook, on high Sierra, now also using it on Mojave and it still works.
you must make sure that the exchange server is auto discoverable and the permissions on the folders are correct.

[Malcolm]

as mentioned above.... it works for me, just the end user has to allow osascript to edit outlook. If the end user doesnt it wont work.

allowing the trust of the script within automation should bypass this problem.

[Kyuubi]

Has anyone got this working with machines using Centrify to bind to AD? Adding Centrify in our environment broke my working script.

[Malcolm]

@Kyuubi Is that a AD account management application which doesn't actually bind the device to the domain?

what sort of email solution are you using?

[Kyuubi]

@Malcolm Centrify is what we use to PIV cards. We bind to AD with that. We are using Outlook 2016

[Malcolm]

@Kyuubi

The MacBooks are binding to AD right?
What exchange are you using ? Or office 365 exchange online?

[talkingmoose]

@Kyuubi, I'm not familiar with Centrify, but if it exposes Active Directory nodes similar to the macOS AD binding, you may be able to determine the path and fix your script.

In Terminal, enter dscl and press Enter. This will put you into interactive mode in dscl.

Then, just type ls and press Enter. That will list the top level directory node.

When bound to Active Directory using the macOS plug-in, the results look something like

/Active Directory
/Local

/Search

Do you see something Centrify specific here? If so, you can use cd to change directory into the node. Something like:

> cd /Active Directory

Then list the contents you see there.

This method of using ls to list and cd to change directory effectively lets you walk through your directory service via command line.

[Malcolm]

I may have solved the sandboxing to tell outlook to configure without user permission...

sudo spctl --add /Library/Talking Moose Industries/Scripts/Outlook Exchange Setup 5.5.4.scpt

except I'm not on my network at the moment or bound to AD... so this won't be confirmed until Wednesday.

[Malcolm]

ahh the joys of vpn...

testing is showing it won't make it into the automation trust unless the script is compiled exported as an app.

stay tuned.

[Malcolm]

@talkingmoose

so this is the path of the data that gets changed when trusting a script app file to allow access to other applications...

~/Library/Application Support/com.apple.TCC/TCC.db

its user associated, but the db is sql light and well this is as far as my skills go.

initial tests show that if I copy the file with the activated state, then turn it off
then delete the original and return the previous with the activated state that it will remain as trusted.

Interestingly, this appears to only affect the automation security options

so I can only assume that this will allow me to deploy the same file to end users using Jamf - at worst it is likely to delete any previously trusted automator preferences, but this won't be an issue for my end users.

so exporting your script .app and then trusting it through the above, appears to remove this prompt.

I will try it on a new user next, and then during the week a different MacBook, to ensure the file isn't MacBook specific (which I am hoping it won't be, but possibly will be.

[Malcolm]

Looks like duplicating the previously trusted ~/Library/Application Support/com.apple.TCC/TCC.db. to each individual user, has overcome the osascript security trust. - although path to file will have to always be the same.

I will have to test it onto another machine, to ensure the database isn't machine specific.

in an ideal world it would be ideal to inset the necessary database entries into the db, as replacing it could impact some previously set permissions by the end user.

With admin granted permission this could be quite exploitable.

However this feature could come in handy for good automated purposes.

[Malcolm]

@talkingmoose further investigation with jamf support required the following to be done (rather than replacing the tcc.db)

https://www.jamf.com/jamf-nation/articles/553/preparing-your-organization-for-user-data-protections-on-macos-10-14

I had to convert the scpt file to a app for it to be done, as the PPPC utility application currently doesn't support the ability to profile trust scpt files... a bit of modifying later, I have a working solution.

[Malcolm]

@talkingmoose

So I cant confirm for sure if I needed to change the scpt into an app at the moment, what I found was the sh script was causing the osascript permissions request to edit outlook, rather than the scpt, but it still may have been as even using the ppc utility on the app version it wouldn't proceed when it executed from the .sh file

what I found was to use the pppc utility to trust osascript to access outlook.

I now have a fully functional solution, no permissions prompts, and I added a display prompt that expires within 5 seconds in the code to inform the end user they need to put in their password when prompted for office 365 authentication, after the account is created.

[talkingmoose]

@Malcolm, sorry for the delayed response. I've been busy globetrotting and meeting with customers. Glad you found your solution.

Since you mentioned Office 365, this may be a better option than the script. It's the blog post I alluded to earlier.

Help users activate Microsoft Office 365 and configure Outlook in one click

[mgshepherd]

Thanks @talkingmoose for the link, I've been wanting to find this info from the JNUC conference.

[Malcolm]

@talkingmoose Hmm interesting article. I might look into that. Our office 365 is the license activated one, and not office 365 sign in activated. so its currently sits at 16.16.4.
I always noticed that the sign in activated version is always a few versions ahead.

But what you have provided around this problem has been a god send.

[tim_rees]

Hi All,

I've been using this script for a couple of years, and absolutely loved it, so thanks @talkingmoose for all the effort!

I'm currently testing my Mojave deployments (and making more PPPC profiles then ever thought imaginable), and after allowing osascript to access outlook, I get an error "Sorry, something went wrong and <a> was unable to start. (<d>)"

Has anyone seen this, or have a fix for it? or is the best solution to re-visit the whole provisioning of Outlook process into an App as mentioned a few posts above?

Thanks in advance!

[KyleEricson]

@talkingmoose Quick question can you get Outlook 2019 setup to authentication with cert based authentication? This would be ActiveSync on Office 2019 on prem AD and exchange.

[talkingmoose]

@kericson, not today, but I know @jeffkalv (PM for Outlook for Mac) heard this at least a couple of times along with requests for smart card support while he was visiting with folks at JNUC this year. I believe it's in Microsoft's sights but not quite yet on their RADAR.

While this isn't quite what you're asking for, I think this feature request aligns with what you're wanting and the technologies that are moving forward in macOS. Definitely, vote this and other features you'd like to see implemented voted up. Many of the recent feature implementations have been coming from the requests here.

https://outlook.uservoice.com/forums/335538-outlook-for-mac-business/suggestions/20119960-ctk-suppor...

[KyleEricson]

@talkingmoose Ok one other question how would you do a MDM profile for the TLS handshake with a load balancer via Outlook 2019 to exchange on-prem?

[talkingmoose]

@kericson, I'm not understanding your request here.

How does Outlook 2019 relate to a load balancer? The application itself has no clue what a load balancer is. It can use a certificate to authenticate a user to an Exchange server but that's authentication vs. encrypting traffic.

[KyleEricson]

@talkingmoose Sorry for the misunderstanding. How can a user authenticate with a cert via Outlook with on-prem exchange?

I found this setting in Outlook, but can't find a way to script or plist for it.

[talkingmoose]

@kericson, ah, gotcha.

Not possible at the moment, unfortunately. That's one of the few areas in an account that's not scriptable and I'm pretty sure the setting isn't stored in a plist because account settings are generally stored in the SQLite database for the Outlook profile.