Outlook 2016 autoconfigure

hkabik
Valued Contributor

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.

1 ACCEPTED SOLUTION

talkingmoose
Moderator
Moderator

More stuff ready for anyone who'd like to test...

I've devised a launchd setup that works well for me in my testing to automatically configure Outlook 2016 the first time it's launched. After a lot of research into launchd QueueDirectories and WatchPaths, the WatchPaths made the most sense because I can monitor for the existence of specific files. (Thanks, @eholtam, for your ideas. I adapted them for my own changes.)

The whole setup consists of one LaunchAgent file and two scripts. The only file you need to customize is the AppleScript. Everything else can just drop in place. The ROOT folder simply designates the "root" of the hard drive or "/". For now, be sure to keep the names and paths of the files and folders the same as I've created them unless you're comfortable changing the references in the three files.

I've also made minor changes to the AppleScript itself to better accommodate all potential settings not just Active Directory as well as accommodate this new setup.

You'll find everything here: https://github.com/talkingmoose/Outlook-Exchange-Setup-5.0

Click the Download ZIP button to the bottom right and locate these files in the ROOT folder:

  • /Library/LaunchAgents/net.talkingmoose.OutlookExchangeSetupLaunchAgent.plist
  • /Library/Talking Moose Industries/Scripts/Outlook Exchange Setup 5.0.scpt (customize this)
  • /Library/Talking Moose Industries/Scripts/OutlookExchangeLaunchAgent.sh

Feedback, as always, is greatly appreciated.

View solution in original post

220 REPLIES 220

AdamH
New Contributor II

So, I did some looking and it seems its not really a bug as much as its a configuration spec.
We've been getting ready to use O365 accounts here, and in doing that have been changing the UPN in our AD template. Once that change was made to a test account, the user was able to actually log in with the email address in that field (username worked as well).
So it seems the behavior is expected, and will work if the UPN field in the AD account is set to O365 standards.
Which is cool.....I guess.....

Look
Valued Contributor III

@eholtam I used my own setup script (with some sneaky peeks at @talkingmoose 's scripting) but got round the smoking gun as it were by doing the following.
The first thing the script does is check if there is an exchange account, if it finds one, it simply exits and unloads the launchagent. Thereby leaving it not running for the rest of the session.
The launch agent will run every login, but immediately unloads for any user that already has Outlook configured without interfering with anything however if a tech was to delete the monitored folder and exchange account the log out then it would be active again when the user next logged back in and once again reconfigure Outlook.

eholtam
New Contributor

@Look Care to share your Exchange detecting code snippet?
When the script runs every login wouldn't it have to launch Outlook to be able to determine if an account exists or not?

Look
Valued Contributor III

@eholtam Sure I am calling apple script from shell, so in the shell part of the script I get my user with my preferred

Current_User=$(stat -f%Su /dev/console | awk '!/root/')

which will return any none root console user.
Then I have a function.

Get_Current_State() {
if [[ "$Current_User" ]] && [[ "$(ps -cax | awk '/Microsoft Outlook/')" ]] && [[ "$(defaults read /Applications/Microsoft Outlook.app/Contents/Info.plist CFBundleShortVersionString | awk -F "." '{print $1}')" == "15" ]] && [[ -z "$(find /Users/$Current_User/Library/Group Containers/ -name *olk15MailAccount)" ]]; then
    return 0
else
    return 1
fi
}

Basically it checks for a user grabbed earlier, makes sure Outlook is running and that version 15 is installed (it might still fall over if 2011 was installed and open as well) then searches the profile directory to make sure there is no olk15MailAccount file.
You can then use it in the following context

if Get_Current_State; then
DO SOME STUFF ie CALL AN APPLESCRIPT
fi
UNLOAD THE AGENT

Basically the first time the Queue trigger activates it either skips everything and disables the agent or does the script then disables the agent.

Look
Valued Contributor III

It did also occur to me that you could also just have the disabling of the agent inside the agent itself as another program call, then the script just needs to check and configure or no configure as required and the agent would only ever run once per session either immediately if there were items in the directory or at the point in which the directory is populated.

talkingmoose
Moderator
Moderator

Disabling the launch agent for the session is actually a brilliant idea! I like that.

Wouldn't be too difficult to detect an Exchange account without launching Outlook.

profile=$( defaults read "/Users/$USER/Library/Group Containers/UBF8T346G9.Office/OutlookProfile.plist" Default_Profile_Name )

if [ -d "/Users/$USER/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/$profile/Data/Exchange Accounts" ] ; then
    echo "Exchange account present"
else
    echo "Exchange account not present"
fi

This seems to work in my very limited testing.

eholtam
New Contributor

@talkingmoose

The existence of the Exchange Accounts folder isn't enough as that folder structure remains even if all Exchange accounts are deleted from within Outlook. I used a hybrid of yours and @Look's code to come up with.

profile=$( defaults read "/Users/$USER/Library/Group Containers/UBF8T346G9.Office/OutlookProfile.plist" Default_Profile_Name )

#Check if an Exchange profile exists or not
if [ -z $(find "/Users/$USER/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles/$profile/Data/" -name *olk15ExchangeAccount) ]
then
    #If no LaunchAgents directory exists in the user home, create it
    if [ ! -d $HOME/Library/LaunchAgents/ ]
    then
        mkdir -p $HOME/Library/LaunchAgents/
    fi

    #Copy the LaunchAgent to ~/Library/LaunchAgent and load it
    cp "/Library/Management/Outlook2016Setup/LaunchAgents/net.talkingmoose.OutlookExchangeSetup5.0.plist" "$HOME/Library/LaunchAgents/net.talkingmoose.OutlookExchangeSetup5.0.plist"
    launchctl load "$HOME/Library/LaunchAgents/net.talkingmoose.OutlookExchangeSetup5.0.plist"
else
    exit 0
fi

That worked for all scenarios that I tested. Once the *olk15ExchangeAccount file no longer exists the setup process is made available to the user again.
The launchagent that gets loaded in the ~ space is

<?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>Label</key>
    <string>net.talkingmoose.OutlookExchangeSetup5.0</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/osascript</string>
        <string>/Library/Management/Outlook2016Setup/Scripts/Outlook Exchange Setup 5.0.scpt</string>
    </array>
    <key>WatchPaths</key>
    <array>
        <string>~/Library/Group Containers/UBF8T346G9.Office/OutlookProfile.plist</string>
    </array>
</dict>
</plist>

And the applescript has two lines at the end to remove the ~ LaunchAgent and unload it.

do shell script "rm $HOME/Library/LaunchAgents/net.talkingmoose.OutlookExchangeSetup5.0.plist"
do shell script "launchctl remove net.talkingmoose.OutlookExchangeSetup5.0"

This may be my winner winner rubber chicken dinner. Thanks for both of your insights.

AdamH
New Contributor II

I love the idea of a launch agent- its self contained and doesn't rely on anything else.
But what I'v been doing with 2011 so far and could work with 2016 as well, is add this to the beginning of the script:

tell application "System Events" if exists (folder "~/Library/Containers/com.microsoft.Office365ServiceV2") then error number -128 end if
end tell

... and add the script as a login script. It will run every time the computer is logged in for every user and it will just quit if an account has been created already.

I'd have a version without this in self service in case someone wants to recreate their account for some reason.

talkingmoose
Moderator
Moderator

@AdamH, this is purely administrative philosophy.

My reason for having the launch agent watch for specific items is to avoid confusing the user. When he or she launches Outlook, that's when I want setup to run. The user will understand the act of launching Outlook just triggered something. If all script prompts are suppressed, the user doesn't even realize setup just ran and simply logs in to email.

Otherwise, running the script at login automatically launches Outlook, whether the user wants that or not.

Self Service would be a good additional place to add the script if the launch agent fails or we haven't built enough smarts into the script to account all the potential scenarios when it may not trigger.

AdamH
New Contributor II

I think your philosophy is sound. Personally I think it would be the optimal way to go.
But in my environment, we have a deployment team that issues all new computers. So in this scenario having Outlook automatically launch and setup the account for the user is a bonus because it ensures that Outlook is configured and working before the tech leaves.

Oh, and millions of thanks for doing the legwork in developing this script with great documentation! Its saved the scripting-impared many hours of work and related headaches!

talkingmoose
Moderator
Moderator

I've appreciated all the help with the first run stuff. It's time I haven't had to devote to testing, which is why I posted everything as-is on GitHub.

Next, I'll steal ideas and give credit where due. And I'll update everything and put a bow on it. :-)

talkingmoose
Moderator
Moderator

More stuff ready for anyone who'd like to test...

I've devised a launchd setup that works well for me in my testing to automatically configure Outlook 2016 the first time it's launched. After a lot of research into launchd QueueDirectories and WatchPaths, the WatchPaths made the most sense because I can monitor for the existence of specific files. (Thanks, @eholtam, for your ideas. I adapted them for my own changes.)

The whole setup consists of one LaunchAgent file and two scripts. The only file you need to customize is the AppleScript. Everything else can just drop in place. The ROOT folder simply designates the "root" of the hard drive or "/". For now, be sure to keep the names and paths of the files and folders the same as I've created them unless you're comfortable changing the references in the three files.

I've also made minor changes to the AppleScript itself to better accommodate all potential settings not just Active Directory as well as accommodate this new setup.

You'll find everything here: https://github.com/talkingmoose/Outlook-Exchange-Setup-5.0

Click the Download ZIP button to the bottom right and locate these files in the ROOT folder:

  • /Library/LaunchAgents/net.talkingmoose.OutlookExchangeSetupLaunchAgent.plist
  • /Library/Talking Moose Industries/Scripts/Outlook Exchange Setup 5.0.scpt (customize this)
  • /Library/Talking Moose Industries/Scripts/OutlookExchangeLaunchAgent.sh

Feedback, as always, is greatly appreciated.

eholtam
New Contributor

Thanks, @talkingmoose, for the continued development and followup posts. I'll take a look.

AdamH
New Contributor II

For this new setup- should the LaunchAgents and scripts be going into the regular Library folder or the User's library folder?
The script at the end of the AppleScript references $Home.

talkingmoose
Moderator
Moderator

Posted scripts and the LaunchAgent all go in /Library in the locations I mentioned above.

As needed, one of the scripts will create a temporary LaunchAgent in the current user's home folder, but that's automatic.

AdamH
New Contributor II

OK, I thought so, but when it didn't work I thought I may have had it wrong. Turns out when I manually went through the steps I had the permissions wrong.

I did get it working like a champ yesterday- so I made a package with the files in their working configuration.
However when I put it on a new machine the initial Launch Agent doesn't seem to kick off the script to create the user's launch agent. I confirmed that the agent did load, but it just didn't trigger that script.
Going to do some more futzing around....

eholtam
New Contributor

The script name the LaunchAgent is calling isn't the same as the actual script in the current repo. Check the /L/LA and verify the script it is calling matches the name of script in /L/TMI/scripts/.

I have a PR on the repo to address that.

-Eric

shoegazer
New Contributor

i cant get this to work either, the only changes i made were to the applescript left the rest the same except for the launchagent which had the sh script named incorrectly as mentioned by @eholtam above. No launchagent is created.

talkingmoose
Moderator
Moderator

Thanks again, @eholtam!

I've corrected the script name to match the launch agent.

plawrence
Contributor II

@talkingmoose Just a quick post to thank you again for all your work on this. I've been deploying your the files as-is and they've been working great!

talkingmoose
Moderator
Moderator

Thanks for the feedback, @plawrence! Time to finish the documentation and take care of a few housekeeping issues.

hkabik
Valued Contributor

@talkingmoose

Really can't thank you enough for your efforts on this.

shoegazer
New Contributor

@talkingmoose @eholtam forgot to mention i got this working, thanks guys :)

TimT
Contributor

@talkingmoose Another big thank you for the work here! Brilliant stuff, very slick.

I am seeing one curiosity that has me baffled. Deploying Outlook 2016 v15.15 on 10.11.1 and using kerberos launches Outlook and creates user account perfectly first time. After allowing the account to sync with exchange and upon subsequent launches it spawns new accounts called "Untitled Exchange Account". A new account is added everytime Outlook is launched.

I have trawled through the script in an attempt to work out why this would be happening but nothing has stood out. Also happens when kerberos is set to false and username and password are used as @Abdiaziz mentioned earlier. Any clues here?

Cheers
Tim

eholtam
New Contributor

@TimC

It sounds like the LaunchAgent from the user space isn't being removed properly after the AppleScript is running.

On a machine that is showing this behavior can you manually run the AppleScript from Script Editor.app and view the Events of the script?

-Eric

talkingmoose
Moderator
Moderator

@TimC, just now seeing this. Mr. @eholtam has provided the same response I'd have.

Toward the latter part of the script is a section called "Begin account setup". You'll see several "try" and "end try" lines. In AppleScript, "try" means "execute the following lines of code, but if something fails don't stop the script".

It's possible to comment these lines using two dashes "--" at the beginning of each one. If you see a line that says "on error" then add the dashes to it and the rest of the section until you come to "-- end try". Run the script manually on the machine in Script Editor. It should stop at the part of the script where it fails.

This should help you troubleshoot.

benbass
New Contributor III

I ran into this same issue. I was able to unload the created LaunchAgent, but was unable to delete it. I altered the checking script to remove the spawned LaunchAgent if the account was already setup. Since the spawned LaunchAgent is unloaded it won't run a second time, and when a restart/login happens, the script deletes the LaunchAgent. I tried deleting the LaunchAgent from within the AppleScript, but the AppleScript just would not delete or move the LaunchAgent when called via a LaunchAgent.

And the end of the check-if-setup.sh I have this:

    if [ -e "$profile_loc" ]; then
        launchctl unload "$HOME/Library/LaunchAgents/net.talkingmoose.OutlookExchangeSetup5.0.plist"
        rm "$HOME/Library/LaunchAgents/net.talkingmoose.OutlookExchangeSetup5.0.plist"
    fi

eholtam
New Contributor

@benbass

Interesting. I assume since the script is called "check-if-setup.sh" you're using my fork as @talkingmoose's script is "OutlookExchangeSetupLaunchAgent.sh." Did this issue happen on multiple machines or just one you were testing on?

What was the owner/group/permissions on the ~/Library/LaunchAgent when it wasn't able to be deleted?

The check-if-setup.sh runs as the logged in user and is supposed to abort if an account exists already. It shouldn't create the ~/Library/LaunchAgent if the Exchange account exists.

-Eric

benbass
New Contributor III

@eholtam Yep - I built it off your fork. I don't remember the permissions, but if I ran the script in the users context manually it worked just fine and unloaded, then deleted the script. It was only when it was automated that the LaunchAgent wasn't deleted.

I added my bit to clear the LaunchAgent after a successful creation, as the LaunchAgent was still there but unloaded. If you logged out and back in, the LaunchAgent was still there, so it went ahead and attempted to create the account - which was already created.

chad_fox
Contributor II

@talkingmoose Thanks for sharing the Exchange setup!

So far everything works as expected except the password field. Once a user logs in the username populates and the login appears successful, but the password field is left blank. I've tested with and without the keychain checkbox selected with the same issue.

Once I open preferences and manually enter in the password mail begins to sync as expected.

I'm using the domain prefix username authentication method if that helps.

talkingmoose
Moderator
Moderator

@chad.fox, I really appreciate the feedback.

Unfortunately, the password field is completely out of the script's control. When a user sees the prompt to enter his or her password, the script is already complete. That prompt comes from Outlook itself.

Can you verify the username field is actually populating correctly? If so but the password isn't sticking, then we may need to open an issue with Microsoft.

benbass
New Contributor III

@chad.fox @talkingmoose I had the same issue with my AppleScript as well. The account get setup, but when first prompted for the password, you enter the password, and can even select to save it to the keychain, but no password gets saved.

My solution was to add a dialogue to the account creation and have the user enter the password so the AppleScript catches the password and generates the account with the captured password. So far that has been working properly where the account is created and the exchange account starts synchronizing immediately.

chad_fox
Contributor II

@talkingmoose Everything is populating correctly, super smooth setup. The only hitch was the password field saving the users credentials.

@benbass can you post an example of what you're implementing in the AppleScript? Sounds like that might be a fix for me.

benbass
New Contributor III

@chad.fox @talkingmoose Here is the entire --Begin account setup portion. My additions are fairly minor - the --Grabbing Users Password, and then password:userPassword in the --create the Exchange Account.

On a different note I also added a check for Office 2011. If 2011 is installed you can skip the process as you cannot import 2011 data into an identity that has an account already configured.

I can post that if people are interested.

--------------------------------------------

-- Begin account setup

tell application "Microsoft Outlook" activate try set group similar folders to unifiedInbox end try try set hide on my computer folders to hideOnMyComputerFolders end try if verifyEMailAddress is true then set verifyEmail to display dialog "Please verify your email address is correct." default answer emailAddress with icon 1 with title "Outlook Exchange Setup" buttons {"Cancel", "Verify"} default button {"Verify"} set emailAddress to text returned of verifyEmail end if -------------- --Grabbing Users Password set getUserPassword to display dialog "Please enter your password" with icon 1 with title "Outlook Exchange Setup" default answer "" buttons {"Cancel", "OK"} default button {"OK"} with hidden answer set userPassword to text returned of getUserPassword if verifyServerAddress is true then set verifyServer to display dialog "Please verify your Exchange Server name is correct." default answer ExchangeServer with icon 1 with title "Outlook Exchange Setup" buttons {"Cancel", "Verify"} default button {"Verify"} set ExchangeServer to text returned of verifyServer end if -- create the Exchange account try set newExchangeAccount to make new exchange account with properties ¬ {name:"Mailbox - " & userFullName, user name:domainPrefix & userShortName, full name:userFullName, email address:emailAddress, server:ExchangeServer, use ssl:ExchangeServerRequiresSSL, port:ExchangeServerSSLPort, ldap server:DirectoryServer, ldap needs authentication:DirectoryServerRequiresAuthentication, ldap use ssl:DirectoryServerRequiresSSL, ldap max entries:DirectoryServerMaximumResults, ldap search base:DirectoryServerSearchBase, receive partial messages:downloadHeadersOnly, background autodiscover:disableAutodiscover, password:userPassword} on error -- something went wrong display dialog errorMessage & return & return & "Unable to create Exchange account." with icon stop buttons {"OK"} default button {"OK"} with title "Outlook Exchange Setup" error number -128 end try -- The following lines enable Kerberos support if the userKerberos property above is set to true. if useKerberos is true then try set use kerberos authentication of newExchangeAccount to useKerberos set principal of newExchangeAccount to userKerberosRealm on error -- something went wrong display dialog errorMessage & return & return & "Unable to set Exchange account to use Kerberos." with icon stop buttons {"OK"} default button {"OK"} with title "Outlook Exchange Setup" error number -128 end try end if -- The Me Contact record is automatically created with the first account. -- Set the first name, last name, email address and other information using Active Directory. set first name of me contact to userFirstName set last name of me contact to userLastName set email addresses of me contact to {address:emailAddress, type:work} set department of me contact to userDepartment set office of me contact to userOffice set company of me contact to userCompany set business phone number of me contact to userWorkPhone set mobile number of me contact to userMobile set business fax number of me contact to userFax set job title of me contact to userTitle set business street address of me contact to userStreet set business city of me contact to userCity set business state of me contact to userState set business zip of me contact to userPostalCode set business country of me contact to userCountry set business web page of me contact to userWebPage -- Set Outlook to be the default application -- for mail, calendars and contacts. set system default mail application to true set system default calendar application to true set system default address book application to true -- We're done. end tell

chad_fox
Contributor II

@benbass Thank you! That worked perfectly, I've tested it multiple times without issue.

I was able to add the additions in your script to the Outlook Exchange Setup 5.1.0 script. Each time exchange was able to sync automatically.

tim_rees
Contributor

Hey All,

I was having major issues with this script, and then on closer inspection found that users did not have LaunchAgent Folders... Is this normal for a freshly installed 10.11.2 machine? ie has anyone else seen this issue?

I thought I was going mad originally, as I knew a @talkingmoose solution would never have this level of trouble.

Thanks.

benbass
New Contributor III

@tim.rees That is correct - a fresh 10.11.2 and even 10.10.5 user does NOT have a LaunchAgents folder. I have my variant of the script make the ~/LaunchAgents folder if it needs to write the setup launch agent.

tim_rees
Contributor

Thanks @benbass

Good to know if the folder is created that it will work! I will go and find your variant of the script and have a look.

benbass
New Contributor III

@tim.rees I guess I should post my variant then shouldn't I. :) I also just thought of something to add as a check if the setup has already been done, as I just had the launch agent load again for the setup while outlook was already open.

I'm thinking of having a file or plist created at the end of the Apple Script, and then have the script check for that file.

I'll work on that and see about posting a sanitized version of my scripts this week.

tim_rees
Contributor

@benbass I assumed it was forked on GIT :-)

Chances are I will need this LaunchAgent folder for more projects, so I would be tempted to make a LaunchAgent that creates the user launchagent folder with the right permissions if it is not found!

Speaking of which, can you confirm what permissions you believe need to be on the LaunchAgent folder in the user library?

Thanks.