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.

[jrserapio]

+1 to this.

[gachowski]

He did a preso, that is on youtube, were he said he was working on it.. However with Apple sandboxing you never know.

C

[kstrick]

Yeah, i think @talkingmoose got the script to more or less work, but I think triggering is the whole problem... i was thinking of maybe creating a launchagent/launchdaemon to run that script that would run once when Outlook starts up, but not sure how smoothly it would work... maybe trigger on creation of a /Users/USERNAME/Library/Group Containers/UBF8T346G9.Office/Outlook/Outlook 15 Profiles folder?

[talkingmoose]

Yes, launchd using watched files/folders seems to be working well in my testing so far. The issue I've had to overcome is the welcome window. Easy to do with configuration profiles and a little GUI scripting. Still working on this but that's the method I'm looking at using right now.

[hkabik]

Good to know. I was thinking I could work my way around any changes to the script itself but for the life of me I couldn't figure out a reliable trigger method. Great to know you're on top of it! Thanks for your hard work!

[plawrence]

@talkingmoose

Any news on a new version of the Outlook Exchange Setup script for Office 2016?

[talkingmoose]

This is still a work in progress, but I've uploaded what I have so far to GitHub.

https://github.com/talkingmoose/Oulook-Exchange-Setup-5.0

The AppleScript itself should be ready for those who use it standalone as a double-clickable script or add it to Self Service. You'll find it in "ROOT/Library/Talking Moose Industries/Scripts/Outlook Exchange Setup 5.0.scpt".

What's not done yet is the launchd agent to trigger the script at first launch of Outlook. I'm still trying to find the right combination of items for the agent to watch.

Also, the guide is only updated through about page 24.

The overarching method I'm using is:

1. Use a configuration profile to suppress the Outlook first run window. This works so far.
2. Use a launchd agent to watch specific folders to know Outlook has been launched. Then run the script.
3. From there, the script runs the same as older versions with a handful of changes.

As I make more progress I'll post more. For the time being, anyone who'd like to test the AppleScript part of the solution is more than welcome.

[rtrouton]

@talkingmoose, thank you!

[kstrick]

@talkingmoose

I've been playing around with a version of the old script that i've modded,
and so far i've had decent luck with a launchagent that watches the following path--
it seems to trigger pretty quickly when you launch Outlook.

~/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/com.microsoft.Outlook/Cache.db-shm

[Aziz]

@talkingmoose Is there a way to change the Outlook "Account Description"? Making everyone's Outlook say "Microsoft Exchange" would be nice.

Changing "use Kerberos" to false sets the Outlook Account Description to "Untitled Exchange account".

[mm2270]

@kstrick As far as I can tell in my testing, this path:

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

doesn't exist on a Mac that has not already had and run Outlook on it previously, so in the case of setting up newly setup/imaged Macs with Office 2016 installed on them, I don't think it'll be possible to use that full path as a WatchPath for the LaunchAgent. The directory doesn't get created as part of the Office installation, only when Outlook first gets launched, and that point its too late.
Launchd's WatchPath function can only watch items (files/folders) that exist. If its not there, the LaunchAgent won't use it as a trigger, and actually removes the path from its internal list of items to watch. @gregneagle has a writeup on this from his blog from years back. (blast from the past) I will have to double check on this, but I believe this rule of launchd jobs is still valid today.

There is the QueueDirectories item for launchd, but the thing about them is that it only works if the directory is not empty, so you can't, for example, use a path like /Library/Containers/ since its already populated with other directories.

I did a little experimenting on this though, and it seems its possible to pre-create the ~/Library/Containers/com.microsoft.Outlook/ directory along with an Office 2016 installation, say as a script run "After", leave the directory empty and then load a user level LaunchAgent watching that directory with QueueDirectories. As long as the permissions are set correctly on the folder, Outlook drops files into that dir upon first launch, and it fires the script pretty quickly. My test script simply put up a basic dialog so I knew it was working. However, as long as the directory remains non empty, the LaunchAgent will continue to run on whatever interval its set to (10 seconds by default unless otherwise specified) so the script would need to run the setup of the account, then either remove itself, or disable the LaunchAgent so it won't run again. Its possible to do, but would take some work and experimenting to get it right.

Edit: I just ran another quick test, and this is even easier than I first thought. While you can't use WatchPaths, you can use QueueDirectories and not even bother to pre-create that folder. Load the LaunchAgent that uses the path of ~/Library/Containers/com.microsoft.Outlook/ as the directory for QueueDirectories. As soon as Outlook launches it creates that directory and the script specified in the LaunchAgent fires. So no need to create the directory ahead of time.

[talkingmoose]

@kstrick, I ran into the same issue you saw with WatchPaths and was considering watching ~/Library/Containers. WatchPaths should only be watching the top level folder and this area shouldn't really change that frequently. And then as part of the script, I was considering adding a check for existing files at the beginning of the script. The presence or absence of those files would determine whether the rest of the script actually executed.

However, based on your results with QueueDirectories, I'll definitely take a looksee there! If that's all it takes, well, the rest is just commentary to complete. :-)

Thanks for the sleuthing and testing!

[talkingmoose]

@Abdiaziz, search within the script and locate this section:

set newExchangeAccount to make new exchange account with properties ¬
            {name:"Mailbox - " & userFullName...

The "name" here is the name of the account. You can change this part of the script to what suits your needs. I originally choose this because it mirrored Outlook for Windows.

[talkingmoose]

@mm2270, my comment to @kstrick should've been directed toward you. Sorry for the confusion.

[Aziz]

@talkingmoose, I did see that part before posting and modified it, the results were the same "Untitled Exchange account". It's being overwritten by something and I need to find out what.

[plawrence]

Thanks everyone for your efforts with this, especially @talkingmoose .

The script works great when I run it manually once the Outlook first run windows are disabled. I modified the LaunchAgent .plist to use the QueueDirectories key instead of WatchPaths, but when I went to load the LaunchAgent I see the following errors:

UserEventAgent Ignoring path: ~/Library/Containers/com.microsoft.Outlook/
com.apple.xpc.launchd[1] (net.talkingmoose.OutlookExchangeSetup5.0[8528]): Service exited with abnormal code: 1

I'll keep testing and let you know if I get it working.

Also, how do you figure out the AppleScript options for Outlook 2016? After an Exchange account is created Outlook appears to set the Preferences -> General -> Hide On My Computer folders to On. This setting prevents the creation of Contact Groups so I'd like to turn it off, do you think that would be possible with AppleScript?

PS. The Github repository is missing the 't' in Outlook (https://github.com/talkingmoose/Oulook-Exchange-Setup-5.0) ;)

EDIT: The AppleScript to turn off Hide On My Computer folders ended up being pretty obvious: "set hide on my computer folders to false"

[fritz_schlapbac]

Many thanks to @talkingmoose for the script! Very helpful. :)

Did anyone figure out how to change the first day of a week to Monday in Outlook? That's the last setting I'm not able to set.

[mm2270]

@plawrence Can you post how your LaunchAgent looks here? I was not seeing an error in my testing using QueueDirectories and the path to the com.microsoft.Outlook container directory. Its possible you just need to adjust the LaunchAgent to get it to work.

[kstrick]

@mm2270 @talkingmoose Good point on the QueueDirectories in lieu of WatchPaths,
that should work much better.

[plawrence]

@mm2270 I started with the .plist template from @talkingmoose Github repo and just modified the WatchPaths to QueueDirectories. I then tried cutting out some of the parts (the RunAtLoad and the Environment Variables) to figure out where the error was and ended up with:

<?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>Disabled</key>
        <false/>
        <key>Label</key>
        <string>net.talkingmoose.OutlookExchangeSetup5.0</string>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/bin/osascript</string>
                <string>"/Library/Outlook Setup Script/Outlook Exchange Setup 5.0.scpt"</string>
        </array>
        <key>QueueDirectories</key>
        <array>
                <string>~/Library/Containers/com.microsoft.Outlook/</string>
        </array>
</dict>
</plist>

I am testing this on 10.11 too if that helps. Let me know if you spot anything wrong!

[mm2270]

@plawrence I can't say I see anything particularly wrong with the plist you posted above. The QueueDirectories section looks identical to the one I used in testing. There are other differences in mine, but that's because I created it myself in LaunchControl, not downloaded the one from the github page.

You said you edited yours and I'm wondering what method you used to edit it, and if you made sure to correct permissions on the plist file afterwards. Launchd jobs are very particular about ownership and perms on these configuration plists it uses.

Another question is, did you try using the LaunchAgent prior to making the edit, and if so, was it working or loading correctly at that point? I'm wondering if it just wasn't working from the start for you or if its somehow the edit of the plist that's causing it not to load now.

FWIW, I created a completely new LaunchAgent that uses QueueDirectories to watch for a non existent folder I just made up, loaded the agent, then created the directory and touched a file to it and it ran the associated script immediately, so the process of using QueueDirectories to look for a folder being created and populated seems to work very nicely. Just need to make sure the launchd job gets disabled afterwards or the script is removed so it doesn't keep running over and over. That's the only pickle left with this to work through.

[mm2270]

@talkingmoose
I've been looking over your Outlook setup script. Great work on this as usual!

While examining it, I wondered if there was some way to make Outlook simply use the Autodiscover process to set up an Exchange account. Right now our Macs are all joined to AD, and all accounts are AD cached mobile. Users typically launch Outlook, go into Accounts, click on the Exchange button and enter their basic credentials, like Domainusername, email address and password, leave the Configure automatically button checked and it figures out the rest to set up their Exchange account.
Is there some way with Applescript to simulate this process in Outlook, so for example. all they would need to do is enter their password (since we can get the rest of the information from their cached AD mobile account)?

[Look]

@plawrence Not sure why but when I made my LaunchAgent it didn't seem to work when I had direct commands but as soon as I referenced a script directly it worked (I used a shell script for me configuration).
Also I didn't have the

        <key>Disabled</key>
        <false/>

In my one.

[plawrence]

@mm2270 I must be doing something wrong as I still cant get the LaunchAgent to work!

I've tried the following on both 10.11 and 10.10.5:
- Created a new LaunchAgent .plist using Lingon 3 to make sure there were no syntax errors, it had the following contents:

<?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>label</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/osascript</string>
        <string>/Library/Outlook Setup Script/Outlook Exchange Setup 5.0.scpt</string>
    </array>
    <key>QueueDirectories</key>
    <array>
        <string>~/Library/Containers/com.microsoft.Outlook</string>
    </array>
</dict>
</plist>

- Tried both with and without a trailing slash at the end of the QueueDirectories path
- Used the full path to the QueueDirectories path, e.g. /Users/username/Library/Containers/com.microsoft.Outlook/. This made the "UserEventAgent Ignoring path: ~/Library/Containers/com.microsoft.Outlook/" errors disappear
- Changed the ProgramArguments string to a shell script as per @Look's suggestion. The AppleScript still never ran. I added some code after the osascript line to write to a file and could confirm that part was working.

I checked the permissions on the LaunchAgent and made sure it was able to load correctly.

I even changed the .plist to just monitor a folder on the desktop (that didn't exist prior) and then run a script afterwards, all that worked. It just seems to not work when I have both the com.microsoft.Outlook folder and the AppleScript file configured :(

Does someone mind posting the contents of their LaunchAgent that I can test with?

EDIT: changed the QueueDirectories path to com.microsoft.Outlook as per mm2270's suggestion below

[RogerH]

@mm2270 @plawrence I am also having issue getting this to work.

[mm2270]

Hmm. I wonder if its because of the ProgramArguments array pointing to a .scpt file? In the tests I've been doing, I always pointed to a shell script. Let me try pointing to a simple .scpt file with a command similar to above and see what my results are.

[mm2270]

@plawrence I just noticed this in your QueueDirectories path

~/Library/Containers/com.apple.Outlook

That's not the path. Its supposed to be

~/Library/Containers/com.microsoft.Outlook

Can you check to make sure you're using the right path to watch?

[Look]

Mine which is also working is pointing directly to shell script not an Applescript and it has no arguments included.

[mm2270]

I don't think it has anything to do with being pointed to a .scpt file. I changed the existing LaunchAgent I had working with a shell script to point to an Applescript file using syntax like /usr/bin/osascript /path/to/script.scpt
Loaded the LaunchAgent with no errors. Made a change to the directory in the QueueDirectories path and the Applescript ran (it just displayed a dialog on screen) But it worked, so I don't think its related to using an Applescript file.
Something else must be causing it not to work for others here.

[plawrence]

@mm2270 Thanks for picking up on the error in my post, I've modified the QueueDirectories path to be ~/Library/Containers/com.microsoft.Outlook (and edited my previous post incase anyone copies it) but I am still having trouble getting this to work.

If I use the path of ~/Library/Containers/com.microsoft.Outlook when I go to launch the LaunchAgent the following error appears in the system log:

UserEventAgent Ignoring path: ~/Library/Containers/com.microsoft.Outlook/

If I change the QueueDirectories path without the ~ e.g. /Users/username/Library/Containers/com.microsoft.Outlook/ then the LaunchAgent appears to work correctly and it attempts to trigger the script when the folder is created, but the following errors appear in the system.log and the AppleScript never runs:

com.apple.xpc.launchd Service exited with abnormal code 1
com.apple.xpc.launchd Service only ran for 0 seconds. Pushing respawn out by 10 seconds

This got me to thinking that perhaps there is something wrong when the AppleScript runs, but I can run it fine manually. After a lot of trial and error I think I figured out what was causing the issue, in the AppleScript there is some code to read the users Active Directory information and it uses a dscl command with a $USER variable, when this script is called by the LaunchAgent it doesnt appear to process that correctly. If I hard-code a username in the dscl command, then the script runs!

For those of you that have this working, had you configured "getUserInformationFromActiveDirectory" to True in the AppleScript?

I also still need to figure out why my LaunchAgent doesnt respect the ~ character in the QueueDirectories path.

[Look]

com.apple.xpc.launchd Service only ran for 0 seconds. Pushing respawn out by 10 seconds

This would seem to imply the directory is not empty and the script is running but taking less than the 10 second default minimum for an agent.
You basically have to have to start with no directory (or at least an empty one) if you want this process to work correctly and the directory existing being a condition of disabling the agent.

Queued directories are intended for mail agents etc... they are not looking for changes, they are looking for content.
Or at least that is my understanding of it...

[mm2270]

@plawrence Sorry if this is a silly question, but the plist for the LaunchAgent is in /Library/LaunchAgents/ correct? Its not in the LaunchDaemon directory by any chance?
Also, what command are you using to load it? Are you loading it from within an app like Lingon or LaunchControl, or from Terminal? If in Terminal, can you paste the command you're using?

Finally, you may want to add the StandardErrorPath and StandardOutPath keys into the launchd file and point them to some stderr and stdout log files respectively. When you load it, and it errors, it should put something in at least one of those files that may help us figure out what's going on.

FWIW, I have set up LaunchAgents pointing to either an existing but empty directory, or a non existent directory in the QueueDirectories path, and its worked for me either way.

[plawrence]

@mm2270 Thanks for the quick response!

Yes, I've put the plist into /Library/LaunchAgents/. To load the Agent I use the following command in Terminal 'launchctl load /Library/LaunchAgents/name.of.agent.plist'

I'll look at putting the error keys into my LaunchAgent and see what the output is.

Did you check if had you configured "getUserInformationFromActiveDirectory" to True in the AppleScript?
Are you currently using the ~ character in your LaunchAgent plist?

[mm2270]

Hey @plawrence, so truthfully I haven't been doing testing with the actual Applescript from @talkingmoose. But I'm still not convinced it has anything to do directly with the Applescript. I've used my LaunchAgent with other Applescripts and not had an issue with loading the LaunchAgent. It should still load as long as you have things set up correctly.
As @Look mentioned above, make sure the ~/Library/Containers/com.microsoft.Outlook folder doesn't exist on the Mac, or if its there, make sure its empty. QueueDirectories works by monitoring a directory for content. It won't run the job until some files/folders get dropped into (one of) the directories its watching.
If the com.microsoft.Outlook dir is already populated when you try loading the job, it will try running the job immediately, so make sure its empty or just not there. Outlook will take care of creating it at first or next launch.

And yes, my LaunchAgent is using the ~ character. LaunchAgents don't have a problem with that since they are always run as the logged in user.
The only thing I'm just seeing that's slightly different from what you posted above is that I included the trailing slash at the end of my path, so instead of ~/Library/Containers/com.microsoft.Outlook, I'm using ~/Library/Containers/com.microsoft.Outlook/ I don't think this should make any difference, but try adding the trailing slash in and see if that helps.

[mm2270]

I just wanted to post back that, once I began actually using the LaunchAgent to watch the actual folder created by Outlook on first launch, I began to see the LaunchAgent come up with errors as well. It was puzzling at first because I could point the LaunchAgent's QueueDirectories path at almost any other location and get it to load and fire a script off as soon as the dir was created and populated with some other files/folders. But when watching ~/Library/Containers/com.microsoft.Outlook/, it began generating errors. This is under Yosemite at least, since I can't install Office 2016 on anything but 10.10 and up.

I think, though not sure, that the reason is because these are sandboxed apps, and the Containers directory it creates are protected in some way, so maybe a LaunchAgent can't actually watch them with QueueDirectories? I don't know for sure since I know little about what happens behind the scenes with sandboxed apps. Maybe someone with some programming knowledge can comment to say whether or not this makes sense or not. I can't figure out why else it won't work. Any folder I make myself and have it watch, even if it doesn't exist initially, works fine. Its just with the actual ones Outlook creates that it all goes south.

If its true that its because of the sandboxing, we may have to just watch the entire ~/Library/Containers/ folder and detect if the com.microsoft.Outlook folder is being created.

[mm2270]

OK, never mind my post above. I just had something configured incorrectly. I was trying to run a script that was calling cocoaDialog, and normally that's OK, but our default deployment of cD sets it so its so the app is not readable by most accounts. This was fixed with a simple chmod -R 755 across the app bundle, so the script run by the LaunchAgent can actually call the application. That's where the error was coming from, not from monitoring the com.microsoft.Outlook directory in the Containers folder. Once I fixed that and put the QueueDirectories path back to ~/Library/Containers/com.microsoft.Outlook/, it works fine. So it seems we can monitor for that and fire a script.

Now to get some other pieces working...

[AdamH]

This may be a silly question- I'm just not up to snuff on my AppleScript.
I think I have the base script configured correctly, and looking at the Accounts info it seems to be.
However, when the prompt dialog box pops up to log into your Outlook account, the username is populated by the user's email address instead of their short name or username.
If you manually enter the username in place of the email address, theres no problem, but you know most users will not.

Is there a place in the script to change this behavior or is this something on my exchange server side?

[nzmacgeek]

Hi @AdamH - this is a known bug in Outlook 2016, as per this issue logged on GitHub: https://github.com/talkingmoose/Outlook-Exchange-Setup-5.0/issues/1

[eholtam]

I'm seeing issues with using the LaunchAgent and using either WatchPaths or QueueDirectories. Both methods are constantly watching for modifications to either a file or whole directory, respectively. In either case this can cause an undesirable launching of one or many instances of the setup script.

In my testing with QueueDirectories watching ~/Library/Containers/com.microsoft.Outlook I was getting the script running 2x during the first launch of Outlook. And if I quit Outlook something was being modified in the watched directory making Outlook launch again and fire up the script. I was getting the same experience with WatchPaths as there isn't a file that can be reliably watched and guaranteed to never be modified again.

The ultimate problem is that 2016 has gotten rid of the Schedules option that Outlook 2011 had. Outlook 2011 was able to have a script run at launch, and as a part of the script, remove itself from the schedule so no other instances would run after it was run once. That behavior, in my opinion, should be mimicked in Outlook 2016 as well, even with the absence of the Schedules option. Leaving the LaunchAgent running as a loaded gun to fire off the setup script anytime the monitored file or path is modified could lead to mis-fires of the setup script even when the account is already setup. What happens when Outlook gets updated? There's no guarantee that a file will remain un-modified for the lifetime of the user account.

I've worked on this in a fork of @talkingmoose's script that tries to implement the change of mimicking the 2011 run-once behavior. In a nutshell, this implementation has a LaunchAgent that checks a custom plist file for a specific key in the user's space to see if the setup script has run. If so, it exits. If not it copies and loads a LaunchAgent in the user's space (~/Library/LaunchAgents) that uses WatchPaths to monitor a file that gets updated only on an Outlook launch. This allows the user to dictate when the script runs as it will only trigger when the application is launched. Once launched the setup script runs and configures the account. I've added 3 lines of code to the end of the AppleScript to write the key value to the custom plist that the main LaunchAgent is looking for on every user login to flag it as having been run, deleting the ~/Library/LaunchAgent and unloading it so it doesn't run again, even if the user quits and re-launches Outlook. This is a run-once behavior like Outlook 2011 had.

The main /Library/LaunchAgent is still loaded and runs a script on every login to check for the existence of the custom plist key. To have the setup script run again you'd just have to remove the custom plist and/or key.

My fork and writeup on this POC can be found at https://github.com/poundbangbash/Outlook-Exchange-Setup-5.0

Note my AppleScript has some custom environment changes, specifically setting the username to the UPN instead of the username. The main difference between the original script and mine are the last 3 'do shell script' lines.

-Eric