Outlook 2016 autoconfigure

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

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.

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.

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....

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

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.

Thanks again, @eholtam!

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

@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!

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

@talkingmoose

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

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

@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

@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

@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.

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

@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

@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.

@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.

@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.

@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.

@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.

@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

@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.

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.