Office 2016 Preview block

Yep, definitely don't want users installing it at this stage!

Are you looking to block the installer?

Yes installer, though I'm having a hard time finding it.

I may just block the apps for now
Course, that makes it difficult because they are the same app names...

Nice. We'll likely see a post on our internal company site from a user wondering why this isn't already showing up in Self Service for them to install and when the h3ll is IT going to start supporting this??? its been a whole hour since its been posted!!

I'm not even joking. The impatience around here from our user base is staggering at times.

@jwojda we had the same thought but blocking the apps will probably be too late! The processes might also be called the same as the 2011 versions.

@mm2270 - i hear you, and know it all too well.

@davidacland - seems they are called the same. just different folder locations... (Installs into /Applications instead of /Applications/Office 2011

Its a pkg installer unfortunately (OfficePreview.pkg) so the process would be the Apple installer. Blocking that would cause more problems.

How about a smart group that detects the new versions, then a policy that deletes them and re-installs 2011?

They claim you can:

Can I run this side by side with Office 2011?
Yes, you can use the preview builds of Word, Excel, PowerPoint, and Outlook for Mac alongside Office for Mac 2011.

And uninstall by:
1. Go to the Go Menu in your Finder Menu.
2. Go to the Applications Folder.
3. Navigate to the Word, Excel, PowerPoint, Outlook, or OneNote app that you want to delete.
4. Drag the relevant app to your trash.
5. Empty the file from your trash.

Now, with 2.5GB of files, is that really "uninstalling"? Nah...

What if you blocked a process name like:

/Applications/Microsoft Word.app

and unchecked the "Restrict exact process name" option? Would that work since it should see the process only if it comes from that path instead of /Applications/Microsoft Office 2001/?
I will need to try that and see if it works.

I would expect that to find both versions of Word and stop them from working, but you never know, could be an easy fix.

Are you still running software from 2001! ;)

Opps! Haha! I meant 2011 of course. :) :)

It looks like blocking the 2016 Apps from running by putting /Applications/Microsoft Word.app in the restricted process works without killing Word 2011 which lives in /Applications/Microsoft Office 2011/Microsoft Word.app.

But I'd wager folks would make a new folder and put them in there after if they are OCD like me.
Or even move them to the Office folder or Desktop.
I"m more interested in blocking the actual install.

FYI, The installer did not ask me to quit Lync or Safari, only Word and Outlook.

LOL - first launch of Outlook - did not choose to import data:

Microsoft Error Reporting log version: 2.0 Error Signature: Exception: EXC_BAD_ACCESS Date/Time: 2015-03-05 18:46:51 +0000 Application Name: Microsoft Outlook Application Bundle ID: com.microsoft.Outlook Application Signature: OPIM Application Version: 15.8.150303 Crashed Module Name: OutlookCore Crashed Module Version: 15.8.150303 Crashed Module Offset: 0x0003d1c4 Blame Module Name: OutlookCore Blame Module Version: 15.8.150303 Blame Module Offset: 0x0003d1c4 Application LCID: 1033 Extra app info: Reg=en Loc=0x0409 Crashed thread: 1

Yes Outlook is bombing out on me with the same error. The previous 150225 beta build is stable though.

Office 2016 requires 10.10.. so if you're blocking that, then you're blocking this!

@boettchs - indeed I thought of that even before I posted that possible solution. Since anyone that would install it is an administrator to start with, they can simply put them into a different path and bypass the restriction. Its by no means a perfect solution, but as of right now it doesn't seem like you can block the installation itself.

The only thing I can think of is to deploy a LaunchDaemon that watches the install.log and if it sees someone is running the OfficePreview.pkg installation it stops it by killing "installer". Seems like a hacky kludge, but I can't really think of anything else that would work at the moment.

We only block 10.10 installs, not new Macs placed into the JSS via enroll, and also, some testers have UAT for 10.10.
It's not critical like Yosemite blocks are, but I'd still like to nuke the installer if possible...

OTOH, if it works as well as it does for me, they'll delete it :)

I can confirm that putting in a restriction like "/Applications/Microsoft Excel.app" as the restriction stops the new versions without blocking the 2011 versions (it requires 4 in total; one for each new app, or 5 if you want to block OneNote also), but as I said, its pretty easily bypassed and could lead to issues if for some reason someone decides to move one of the legit 2011 apps outside of the Microsoft Office 2011 folder for any reason.
Wish there was a better way, but this one could be tricky.

I like the idea of detecting the new versions in an Extension Attribute or some other script, and then targeting those Macs with a deletion script (and optional message that comes up) I may whip something together to do that and post back here with it if I have any success.

Not the best solution by far, but something like this, run as an Ongoing offline policy on the recurring check-in trigger might help

#!/bin/bash

jhPath="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"

restricted="Microsoft Office 2015 applications are currently restricted. These applications have been shut down and removed from your Mac.

Once the final version of Office 2015 is released, IT will evaluate these applications for use in the environment. Please do not attempt to install and use the public beta release at this time."

icon="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/Resources/restrictedSoftware.png"

O2015Apps=$( mdfind 'kMDItemVersion == "15.8*" && kMDItemCFBundleIdentifier == "com.microsoft.*"')

while read app; do
    if [[ $(echo "$app" | egrep "Outlook|Excel|PowerPoint|Word|OneNote") != "" ]]; then
        echo "Found Office 2015 app - $app"

        PID=$(ps axww | grep "$app" | grep -v grep | awk '{print $1}')
        if [ ! -z "$PID" ]; then
            kill -9 "$PID"
        fi

        rm -Rfd "$app"

        removal="yes"
    fi
done < <(echo "${O2015Apps}")

if [ "$removal" == "yes" ]; then
    "$jhPath" -windowType utility -title "" -heading "Office 2015 applications are restricted" -description "$restricted" -button1 "OK" -defaultButton 1 -defaultButton 1 -icon "$icon"

    exit 0
else
    echo "No removals were done at this time. Exiting..."

    exit 0
fi

It locates the new Office applications by the new "15.8" version they show up with as well as their general bundle identifier, then loops over anything found, figures out if the application is running and if so, shuts it down and deletes it from its actual path it was located in, as well as any that aren't running (also from their paths). Then sends up a jamfHelper message that they are restricted. Along with using the standard Restricted Software process, this should help stop most usage, even if someone places them into a different sub directory. In my tests, it safely left the original Office 2011 versions alone and running (if they were open) I also tested moving the apps into a sub folder in /Applications/ called "New" I was able to run them from there with the JAMF Restricted Software processes in place, but when running this script it successfully found, shut down and removed the apps.

Again, less than ideal, but may help. For the moment, I think we'll only use the standard Restricted Software process and see how that goes, but if we need to take an extra step, we can utilize something like this.

SO Glad I'm not the only one looking for this. I thought I was losing my mind when I couldn't block the installer.

Since the preview does not interfere with any of our existing apps, I'm not planning to treat it any differently than any other arbitrary app that a user with admin rights can download and install. We simply won't support it if there are problems, like with any other arbitrary app.

If this impacted Office 2011 I would be singing a different tune. Our users place a very high value on this sort of freedom so I do as well. I'm not saying it's wrong to block it, I'm just curious what the motivation is (I assume to stop users from requesting support for it since it is likely to be buggy?).

Now there is a voice of reason, thanks @alexjdale

@alexjdale I don't wish to speak ill of my users...as most of us are want to do, but your reasoning is correct. It's to try and put a stop from getting an innumerable amount of support tickets that will come in and because it is a Microsoft product, the users will demand support of it's fine and buggy new product.

Also, to avoid the eventual internal politics.

I'm blocking the apps for now because I don't know how they'll impact our E3 licensing yet. It says the apps will be included for subscribers to Office 365 but I don't want to worry about audits or headaches with Microsoft for having preview clients running as main apps on machines in our environment…

That being said, I do have people using the Outlook beta, but not company wide. And I'm hesitant to let the use the Outlook 15.8 app in this release because it crashes repeatedly and once you "upgrade the profile database" or whatever you can't use it with the beta if you put it back on. You then find yourself trashing all sorts of Office settings and files deep within user library preference folders just to get email up and running again.

Also, no Lync included in this, which I find interesting. Maybe Microsoft is going to stop issuing it and just use Skype? If so, are they going to require a Live account to log in and add users? And not be able to sync with a user's offline/cached GAL? These are the things I lose sleep on every night.

Office is not a web browser or social media app. A beta could wreak havoc on Outlook calendars and shared data files. We've had issues with exec's and finance people in the past when some used a pre-release of 2011.

Not to mention, many clients will request this sort of block to avoid inevitable help desk calls and issues with the above.

I don't think the discussion to block these apps is wasteful and if some don't want to discuss or worry, that's awesome too.

Argh. First Apple are allowing public betas, and now Microsoft?

Life as a Mac admin gets more interesting every day.