Best way to handle an Office 2010 to 2013 upgrade with Software Portal?

[Migration User]

 

We're a smaller shop that's still running DS 6.9 for our imaging/software deployment needs but also have SMP 7.1 collecting inventory and doing some patch stuff.  We're getting ready to roll out Office 2013 to our users, and with our initial testing deploying it with a DS 6.9 job, we've found it can take anywhere between 20 minutes to an hour to uninstall the 2010 pieces and install 2013.  (The upgrade doesn't go quite as smoothly, hence our need to uninstall/reinstall).

 

In DS 6.9 we’ve been doing this “on demand” via a job that does the following tasks:

• Kills all running Office 2010 processes on the machine
• Uninstalls Lync 2010 (msiexec)
• Uninstalls Office 2010 (calling the MS setup.exe bootstrapper with an uninstall config.xml)
• Installs Office 2013 (calling the MS setup.exe bootstrapper with an install config.xml)

 

The first two tasks run as local system, the latter two tasks run as our Altiris service acct which has access to the UNC paths of our Office 2010/2013 installers

 

Ideally, we’d give our users instructions on how to access the software portal and request the software when they know they have up to an hour free where they won't need to access Office software on their computer.

 

I was thinking a Managed SWD job enabled for the portal that chains together several “Run Script” tasks that are copy/pastes of my tasks from my DS 6.9 job.  Throw a Run Script task at either end of those tasks to run with the user’s credentials that do a vbscript msgbox that says hey this is going to run as soon as you click OK, and another at the end to say OK it's done, now you can reboot.

 

Not sure if this is best practice or if I should be adding the install info to a command line via Manage > Software and do the actual 2013 install that way instead of a Run Script task that just calls the UNC share?  I would think if Altiris handles copying things down locally it may help with my remote associates not having to stream all of that across the wire as the install is running, but I’m not sure how I would reference the xml file in the command line.  My task in DS 6.9 is \\server\share\setup.exe /config \\server\share\configs\config.xml so I’m not sure if I’d just use relative path, i.e. setup.exe .\configs\config.xml or what.

 

We are also not using a Software Library if that makes a difference.

 

Thank you for any help you can provide!

 

[andykn101]

You can put a Policy into Software Portal.

I'm sure 2013 must be the same as 2010 where you can create an MSP to customise the install that will specify that Office 2010 components are removed.

Create Software Releases for Lync 2010 and Office 2013 with detection rules and the package (not the install command line) pointing to your network location. Make sure the Office 2013 is configured to uninstall 2010. Then create a Managed Software Delivery policy to install Office 2013 and add an uninstall for Lync 2010 too.

 

[Migration User]

In the install/uninstall command line for Office 2010 I have to point to a config.xml file.  If I create the uninstall command on the Office 2010 package (Manage > Software > Managed Software) do I reference the location to that XML file via full UNC?  I'm thinking back to my NS6 days where its cached locally on the client and run as the local system account so it won't have access to network shares.

[Migration User]

Hi Dave!

You could try adding the pre/post install commands to your config.xml (check the "Command Element" section) here http://technet.microsoft.com/en-us/library/cc179195.aspx.

With that you may be able to eliminate the need for additional scripts and leverage a standard package vs. managed delivery and still configure credentials to run this under. This also leverages task vs. managed delivery policy if that matters to you.

Andykn101's suggestion is good too, just depends on how you want to accomplish it.

 /uglysmile

[andykn101]

I never install from network shares, I always put the software into a Package within the Software Release so Altiris will download it locally.

If you put config.xml in the root of the package with setup.exe you don't even have to call it explicitly, setup.exe will find it by default - I found that was the only way to remove the initial splash screen.

But I'd still use the Office 2013 Admin tool to customise the Office 2013 installation, specifying removal of all Office 2010 components.

Or just have an uninstall command for 2010 not requiring package of:

msiexec /x {office 2010 guid} /qn

[Migration User]

It was ugly, but I managed to figure it out.  In case anyone else needs to tackle this, here's how I did this in my environment...

As I mentioned before, all of our software installs are in UNC paths.  Both Office 2010 and Office 2013 install packages were created with the Office Customization Tool built into the installer provided by Microsoft.

Once I "managed" the Office 2013 software item in Manage > Software > Newly Discovered Software, I created a software package and pointed it to that UNC share for Office 2013.

I created a batch file that first manually kills all running Office 2010 processes (taskkill.exe), uninstalls Microsoft Lync 2010 (msiexec.exe /x), uninstalls Office 2010, then installs Office 2013.  I found it necessary to call the Office 2010 uninstall and Office 2013 install commands in separate batch files for them to run properly, as the start.exe command got rather upset when I tried to pass the switches needed for setup.exe to execute properly.  At the beginning of the batch file, I threw in a few ECHO lines to explain to the end user what was going on so they didn't freak out as all of the windows pop up on their computer during the process.

As anyone who's messed with Office 2010 or 2013 knows, you need an XML file to do the silent uninstall, so I just threw that XML file in as part of the Office 2013 package.  When calling the uninstall and install batch files, I referred to them from their location on the client PC (C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\{guid}\cache\uninstall2010.bat)

[andykn101]

Why are you manually uninstalling Office 2010? Does the Office 2013 customisation not do this for you?

To use the start command you should use:

Start "" /wait...

as it uses the first pair of quotes to name the command window but should then use the remaining quotes properly.

[Migration User]

If a user pinned Office 2010 apps to their taskbar, the uninstall through the Office 2013 install would not remove those pinned apps.  The pinned Office 2010 apps would throw errors when the user clicked on them and the user freaked out and called the help desk that "their computer didn't work" instead of unpinning them and re-pinning the 2013 apps.  If we forcibly remove them via uninstalling 2010, the user wouldn't complain.

[andykn101]

Thanks, that's really useful to know.