SCCM deployment of Office to mixed architecture evironments

When deploying Office 2013 as an application in SCCM 2012, some clients fail with "waiting for process xxx to end".  Upon further investigation we learned that the process was a popup window from the installer informing the client that it was unable to install Office because of another Office product that has a different architecture than what's being deployed. 

So our workaround was to create different deployment types for our application based on architecture requirements however we still have a problem with clients who have an additional Office product installed with a different architecture (ie. Project, Visio, Sharepoint Designer).  Because of this mixed architecture of Office application installations, Office 2013 fails until all installed Office applications are the same architecture.

For example:

Client has Office Pro x86 installed on their 64bit system.  Client also has Visio installed but is x64 version.  Because of this, Office 2013 will not install with x64 or x86 versions until Visio is either removed or reinstalled with x86 version.

Is there any other way around this or do we have to perform multiple uninstalls after identifying the mixed architecture Office application installs?

August 15th, 2013 4:28pm

Have you tried using supersedence rules? Using something like that may benefit you more as SCCM would initiate the uninstall based on your application defined in SCCM, rather than waiting for the new Office install to initiate the uninstall. This may allow for Office to install since it would see the machine as having NO Office installed on it currently rather than a mismatched architecture version.

The only other thing you would need to do is make Global Conditions that determine whether the machine needs 32-bit of 64-bit office. You could make these conditions look for things like "What architecture is the machine OS?" and then "What architecture Visio or Project is installed?". Then it would use that logic to choose which Deployment Type of Office 2013 it needs to push to the machine.

Does that make sense?

Free Windows Admin Tool Kit Click here and download it now
April 2nd, 2015 1:24pm

It's been quite a while since I posted that and we've since moved on (I believe our desktop team did a lot of manual work) but the topic still interests me anyway.  Keep in mind I have not revisited this since then.

I'm not sure I understand how your solution fits our scenario.  If we take SCCM out of the picture for a second and look at the problem from a manual installation perspective, I think maybe the problem may be clearer.

Example:

Let's say my system is 64 bit.  I have an old version of Visio installed (2010) that I love and never want removed because I am an end-user and everything I say is important and I'm always right (-_-).  This Visio was installed as a 64 bit application.  I also have 32 bit Project 2010 installed on my system.

Now, my old Office Suite installation has already been uninstalled and I'm ready for the new Office 2013 installation (my Visio and Project still exist).  The desktop team only wants 32 bit installations of Office to be deployed.  When they try to manually install the 32 bit Office software on my machine, they get an error that it can't be installed because there is 64 bit Office software installed (Visio). (In other cases, software like SharePoint designer and Visual Studio were installed throughout the organization in all different architecture combinations)

Because of this, they can't manually install my Office Suite unless they locate and uninstall any 64 bit office application on my system (in this example, Visio).  But I don't want my Project or Visio uninstalled right?  So let's say they make an exception for me and try to manually install the 64 bit Office suite.  They get the same error because my Project installation is 64 bit.

So that was basically the problem.  SCCM wasn't at fault and we were trying to find a solution that didn't require uninstallation of software.  Perhaps I was looking for a registry hack or something where those particular errors could be ignored.  I believe our Desktop team ended up addressing each case individually and forcing the reinstallation of our end-user's beloved software installations matching up all the architectures.

Anyway, thanks for the suggestion but like I said, we've since moved on with other annoyances. ;)

April 6th, 2015 10:17am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics