Now that we’ve established the core goal of the project, to rollout Office 2007 via a KIX logon script with add-ons and all sorts of other lovely goodness, the next thing to do is to find out if there are going to be issues with the rollout, and what after-effects the new software could potentially have on people’s day to day workings.
I would like to point out the simple fact that everyone knows but that is rarely uttered outside closed doors for fear of being struck down with a plague: there are going to be problems.
When upgrading to a newer piece of software that many people are not going to be able to fully use straight away, you will come across comments like their ‘machine’s magically broken’ or ‘my old document does’t open any more’.
A lot of the issues come from legacy documents – you know, the kind that most companies keep until 17 years down the track, just in case it’s ever needed again. Then, of course, there are the users with programming knowledge, who may have programmed macros within the documents, either via the record option within Office, or by taking the time to code in Visual Basic for Applications. To add insult to injury, that lone unrecoverable document may just so happen to be key to the company’s success in making squillions of pounds…
We, as administrators of the system, are not going to know the contents of every single document, because if we did, that would mean a) we do nothing else with our lives, and b) we could come across information we shouldn’t see and therefore open up the opportunity to blackmail….er, I mean, er…never mind…
So, how can we make sure we’ve assessed the risk of as many potential problems in this scenario as possible?
Wel, normally I would be the first to say, we can’t do anything about it. Microsoft on the other hand to have a handy solution.
It’s called the Office Migration Planning Manager or OMPM for short. The idea is that this application will scan areas you specify in an ini file – either just local drives or defined drive letters for network mapped drives – and then read the properties of all supported Office files, looking for any issues that could arise.
Basically after you’ve extracted the files from the download to a folder of your choice, go to that folder. You’ll find a number of subdirectories, which we’ll go into later, but right now, go and look in the folder titled “scan” and you’ll find these;
As you can see from the above picture, the small number of files from Microsoft are only 1.84MB once extracted and can be placed on a network share for all to access, or you can copy the files to the local machine and run it from there. The exe you will be looking for is offscan.exe and this will work with the options placed within offscan.ini. After the officescan program has run its course, the files created are placed within a cab file for you to import into an SQL database of your choice.
However there are a couple of things which should be noted that Microsoft left out of their documentation – but which their engineer inform us about while running the app. It appears the cab creation process goes wrong if you specify a network location for this part of the INI file:
;DestinationPath: the path where the log files will be written to
It appears it fails to make cab files correctly if a lot of activity is going on in the same folder which, for all client machines writing the location at the same time when they all logon in a morning, is not too clever. Therefore the recommendation is to write the files locally on the workstation as shown above with the C:Offscan example folder and then copy the resultant cab files over to a network location.
The other is just to run the scan for locally hosted drives. Basically it’s to stop offscan going off to scan all your network shares for files which could number in the hundreds of thousands. If that’s occuring for mutiple users scanning files at the same time, it has the potential to grind things to a halt.
So basically at the section of the ini where this appears:
;Include all folders you want to be scanned in the FoldersToScan section
;Any folders you want to be skipped should be added to the FoldersToExclude section
;You may include a folder that is a subfolder of one of the folders to exclude
;If there is no entry in this section all physical local drives are scanned.
;The scan stops if a specified folder to scan does not exist on the system.
Don’t write anything extra. Sorted.
Now the best part of this will be the addtion to the logon script which will run the officescan program:
;************* Run Office Scan on All Machines *************
;Added by request of Mr Manager 15th December 2008
If Not Exist (“C:Offscan”)
? “Mapping P Drive for use with OfficeScan Application”
Use P: “\servernameOfficeScan$“
Use P: /delete
Copy “C:Offscan*.cab” “\servernameOffice2007$“
Now the above text is all you really need, a directory which will be created on the local workstation which we will create if it’s not already there (the C:Offscan example is again used here) which is then used for storing the files created during the scan
Also some network shares (hidden or not, it’s up to you) are used, one containing the officescan files as shown in the screenshot above and another for the place where the cab files will be copied to. Finally, remove the temporary drive mapping and copy the files to that nice network location.
You will notice that we simply call a batch file above – runscan.bat – and you’re all wondering what it will contain and is it going to be uber hard and hurt your head?!?! Well, no:
Oh my, tis something beyond the realms of imagination! Though in truth, the reason why we called a batch file was that the officescan was more prone to producing errors when running when called directly from the kix script via an unc path or even the drive letter which in this case is P:, rather than just calling a batch file, which in essence, all it does is change the drive letter to P: and then just run the app. No problems afterwards.
You don’t have to include any checking as to whether or not it’s run before as the app will leave the runid of the scan behind on the user’s profile and therefore will just skip scanning if it has completed before.
If the scan doesn’t run as well you would hope then to get it to run again, you are going to need to change the scanid within the offscan.ini;
;Run ID is a unique ID for this distribution of the scan.
;Description can be used to describe any extra info about the Run. I.E. Month/Year
Change the runid to a different number and you are all set to go. This part is also at the top of the ini file so you don’t have to spend time looking for it either.
As for what you would see, well take a look:
You’re going to need to leave this in the logon script for a few days in order to capture people who may be on holiday, or are on laptops out of the office, but soon you should have a great deal of cab files on the network share to delve through. But what do you do with the cab files once you’ve got all the data you want?
That’s something for next time… (Wish there was a “To Be Continued” jingle with a sinister laugh now…)