Skip to main content

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.

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


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.


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.


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


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


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


@Kyuubi



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


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


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.


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.


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


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.


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


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


@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


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


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


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!


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


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


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


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


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


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


Hey all,



So look like there is no way to use @talkingmoose 's Apple Script with an unbound Mac when trying to setup Outlook 2016 with an on-prem Exchange server (non 0365)?



Thanks,
R