Installing update policy at login without being on ethernet

[bbot]

I have been tasked to update Office to the latest 14.5.1 version. I have the .pkg set to install with a login hook. While this works for a majority of users, the issue is that it only installs when the user is on a physical ethernet cable.

I'm weary of pushing the update as it quits out of all Microsoft programs.

How are you guys deploying office updates to get 100% compliance? Upload to self-service and e-mail users? Is there a way to cache the package locally on their machine, then have a script to execute at first login without being on a physical ethernet cable?

[Look]

Deployed policies have a cache only option for packages
Then you can run

jamf installAllCached

From a scipt (i.e. called at boot or logout or similar) at any time in the future.

[bbot]

@Look Thanks for that info! Also noticed in the Maintenance section of a policy, there's an option for "Install Cached Packages."

From my experience, packages only install from policy with a login hook while connected to an ethernet cable. Is there a way to install the cached package when they login off of a network cable? I want the install to happen during login to avoid having all the Office products quitting while they're using it.

[mm2270]

My guess here is that the policies are not running at login or logout while on wireless because the Wi-Fi connection is getting dropped (when logging out) or not active in time (when logging in)
If that sounds like the case, you may have luck with the following, but I have not tested it.

Have one series of policies that caches your installer packages to the Mac using whatever triggers and frequency makes sense to you. Those packages get cached into /Library/Application Support/Waiting Room/

Set up another policy that simply has the "Install Cached Packages" option enabled under the Maintenance section.
But for trigger and frequency, set up this policy using Logout as the trigger, and use Ongoing for the Frequency, and check the box under Ongoing called "Make Available Offline"
This makes sure the policy itself gets cached to the Mac so when the Mac next logs out, it will see its Offline (can't reach the JSS) and will run the cached policy to install all previously cached packages.

As I said, I have not tested, so this may or may not work. Also, I think the Mac needs to logout at least once while on a wired connection for this to work since it has to run it one time successfully at logout to cache it.

[bbot]

Thanks for the suggestion @mm2270. I'll test that right now.

I can have the package cache at recurring check-in which happens every couple hours. I think that may avoid having the users having to be on a physical connection to cache the package.

[mm2270]

Actually that's not what I meant in reference to caching. I mean in order for the policy to run in an offline mode it needs to first run while connected to the JSS. In other words, if the policy is set to only happen at Logout and to cache it for offline use, the first time it actually runs it still needs a connection to the JSS in order to actually cache the policy details. Then later it can run at any time, even when not on any network. Make sense?

I'm not certain if there's a good way to pre-cache the policy information without it actually running by whatever trigger you've specified.

Edit: OK, not sure if this will work as its a bit of an odd workaround, but here's one thing you may be able to do.
Have the above policy as I described scoped to a single Mac that you are in control of. The Office packages don't actually need to be cached as well. Just scope the Install Cached Packages policy set for Offline use to one system. Leave the Mac wired into your network and log out, or log in, whichever trigger you set for your policy.

Then run this command in Terminal (change the last section to "logout" if that's what it was set to in the policy):

sudo cp -R /Library/Application Support/JAMF/Offline Policies/login ~/Desktop/

This will copy the directory from the Offline Policies folder for that specific trigger to your Desktop. Its going to be a locked directory just so you know. You can unlock it so you can browse it in the Finder with:

sudo chmod -R 755 ~/Desktop/login

Then you'll be able to see the information the JSS caches for offline policy use.

Assuming your one policy is the only item in that folder, you could presumably package that up just like any other item in Composer, making sure the deployment path is into /Library/Application Support/JAMF/Offline Policies/ and then deploy that package to your Macs during the day while they are connected, along with any actual installer packages you want the policy to install.

Later when they logout/login, the cached policy should kick off even if their Mac can't connect to the JSS.

This is all theoretical. I can't say I've run through the entire process to the end so I don't know, but my assumption is it would work.

All that being said, there is probably a more efficient way to do this by utilizing a LaunchDaemon or something that would just run a command like jamf installAllCached

[bbot]

Your explanation makes sense. Based on that, it may not resolve my issue since the people not getting the updates are the users who don't plug into a physical ethernet cable.

I just tested without an ethernet cable and it cached the package (set to cache at recurring check-in).
Then another policy set to install cached packages offline at logout and it installed the update properly.

Stupidly, I did run the sudo jamf recon command before rebooting... I'm going to uninstall and try everything again from the top.

The only downside I notice is that it spins at logout for about 5 minutes while it's probably installing. Not sure how much harm will be done if a user hard powers off their laptop thinking it's stuck.

[mm2270]

@brandobot There is an option under Computer Management > Check-In > Login/Logout Hooks that you can check called "Display status of login/logout hooks to users" or something like that. Its usually not checked by default, but you can enable that and they will see a jamfHelper message come up at login or logout that indicates policies are running, so they know what's happening.

[bbot]

@mm2270 Cool, found it. I'll give it a go. Thanks again for all your help! I really appreciate it.

[bbot]

@mm2270 Confirmed that it caches the policy and installs without being on a physical network cable.

Next steps is trying to get the "display status of login/logout hook actions to users" to work.

[bpavlov]

I would approach this differently. The reason you want to install at log-in is because you do not want Office to quit applications the user may be running. Read this: https://derflounder.wordpress.com/2012/09/26/removing-the-office-2011-installers-application-quit-fu...

It applies to the main Office installer AND Office Update installers.

[mm2270]

I actually do agree with Mr. Pavlov on what he's stating. Normally I would have mentioned how to get Office updates installed without the apps closing down, but I was concerned that sometimes I get a little 'preachy' about that method, and so I refrained from discussing that in this thread. I know its not the most popular way of doing things, and most folks like to play it safe and make sure the applications are closed before installing any updates (which I get). Yet, I do think its an unnecessary worry. I've never had an issue with suppressing the quit function in the Office updates.
I personally use a different method which uses a special "noquit.xml" file to be used with the installer command line and the -applyChoiceChangesXML function, but either way works - ripping the script out or just bypassing it.

[tcandela]

I have 14.5.1 upgrade running on LOGOUT, jamfhelper message pops up informing using what is happening, not to close lid if laptop etc..

we have all iMacs,Minis on ethernet
all mac laptops are supplied with ethernet adapters or connected via cinema display ethernet

running the update since 6/1 with no issues.

Tested the update with an Office app open during logout, no issue for me.

I see that if on Wi-Fi, logout causes the network connection to break, thus policy not executing.

[bbot]

@bpavlov I would preferably like to do it at login as well, but the issue was that the login hook was not triggering unless the user was on a physical ethernet cable. This caused about 25% of our users to not get the update.

Thanks for the link. Does this mean we can remove the "quit out of all office applications before installing" feature and the update will still take affect if the user has Office programs opened?
If yes, when does the update take affect if the program is opened?

On a side note, I tried adding the "Display Status of Login/Logout hook actions to users" and while it does show the status, it just says "checking policy...". The policies do run and install. Is it suppose to tell users which policy is running or is it just the generic "Checking policy" message. @tcandela how did you configure the jamf helper to give out this message?

[mm2270]

@brandobot I believe it just states its running policies, not exactly what policy its really doing. There were some older threads that detailed ways of using other tools, like cocoaDialog, to show exactly what was running, then cocoaDialog got too old to actually display anything at the logout stage and everyone abandoned that approach. Recently, @loceee branched a version of cocoaDialog that fixes the issue of not being able to display dialogs at logout or over the loginwindow, so I suppose it may be an option again.

As for:

Does this mean we can remove the "quit out of all office applications before installing" feature and the update will still take affect if the user has Office programs opened? If yes, when does the update take affect if the program is opened?

Yes, it will install the updates silently and not quit any of the open applications. As for when the update actually becomes active, not officially until the open applications are quit and relaunched. Until then, the old application "code" is still in memory.
There are a lot of approaches to this. I have custom scripts that do the installs using the aforementioned noquit.xml file, then alert the user that Office (or whatever open app was just updated) was just updated so they know to quit and relaunch it when they can, but it does not interrupt what they are doing and there is no need to do installs only at logout or login. In our environment, if we waited for users to logout, we'd never get any patches applied.

[bbot]

@mm2270 That's amazing. I think I'll cache the packages like I was yesterday, remove the quit-all function, then have another policy that installs cached policies at check-in. This should resolve my issues of users not on an ethernet cable getting updates.

[bpavlov]

@brandobot Generally speaking I do not rely on policies running at login or logout especially for major software installs. The reason being is that it can feel like things are slow to the user which may cause them to do very strange things like shutting down and what not.

To the other question, I do not recommend having the Office applications open when doing the install. I check to make sure none of the Office applications are opened by looking at their process name before a policy is run. It gets a bit more involved in terms of setting up multiple policies. I think it's fine to modify that Office installer so it doesnt quit apps (particularly web browsers). However I do not think it's worth the risk to me to run installers/updates on applications that are open. But as @mm2270 that's a personal preference and a risk.

[bbot]

@bpavlov Thanks for your input. I agree with installing at login/logout as it makes it seem slow. I timed performing the office updates at login/logout, and depending on the hardware, times varied from 1 minute 30 seconds to 2 minutes. I feel if I can get a popup to say "installing office updates", this will prevent users from force shutting down their machine. Currently I have the "display status of login/logout hook actions to users" option checked, but the only message it says is "Checking policy" at login/logout.

Would you happen to know how to personalize this message?

[mm2270]

@brandobot Took me a little searching to locate it, but here is an older Feature Request thread where I posted some examples of using cocoaDialog to show policy progress.
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1148
I can't recall now (without reading thru the whole thing again) if this was in response to dialogs/progress bars at logout, or just when a policy is running in general. Since Casper Suite 9 can already display that a policy is running to a user with built in processes, I wouldn't bother looking at it for that purpose.
Also keep in mind this was back in 2013, so ancient history now. I can't say for sure the scripts I posted will still work or not.

As I mentioned before, up until just recently, cocoaDialog got too old to work with anything past 10.7 for displaying over the loginwindow or at logout/login. But there is now a branched build of cocoaDialog that appears can do this again. Just in case you are interested in it, here is where to find the information: https://jamfnation.jamfsoftware.com/discussion.html?id=9432#responseChild88927

Edit: I meant to say that I don't think its currently possible to customize the show policy to user window text, but I've honestly never looked into it, so not sure.

[bbot]

@mm2270 Thank you! I will take a look into cocoaDialog this weekend.

[wmateo]

I had a question regarding this as well. I find that my policies do not deploy to users who are on Wifi interface, and even though I have my policies mostly triggered at check in, I find it that when I plug them in to Ethernet, that is when they receive policy. May of my users are on WiFi and seldom connect to via Ethernet. Any suggestions?

[bentoms]

@wmateo that sounds like a network/firewall issue.

Your clients on wireless will need same access to JSS & Apple as Ethernet.

[bbot]

@wmateo My environment is the same. Doesn't grab policies on wireless, but does on wired. Not a firewall issue here as computers can still receive policies if I set to recurring check-in on wireless. I'm thinking the wireless network isn't connecting fast enough.

[alexjdale]

I imagine if your WiFi configuration is "by user" and connects at login time, the jamf binary could easily fail to contact the JSS if it does not come up fast enough and login policies wouldn't fire.

[bentoms]

@bbot so recurring check-in works, what policy triggers are then failing?

[bbot]

@bentoms @alexjdale Our WiFi is set by user authentication. Login triggers do not trigger unless they are on a wired network. It could be exactly what alex is saying, wifi doesn't connect fast enough so the login trigger fails.

[alexjdale]

This should be pretty easy to prove. Check the JAMF log, I would assume it would show the attempt to check for login policies and say that it couldn't reach the JSS.