On our last exciting encounter in the Office 2007 deployment saga, we had put in place some code to run the Officescan application which scans for files on user’s machines to discover if there are likely to be any issues with legacy files arising once Office 2007 is finally installed on machines.
Now a few days have passed and we have collected a vast number of workstation’s cab files in the location we defined in our offscan.ini file.
Before we start with what we do with those cab files, there is one thing which may have popped up in your head while reading the last entry; what happened to scanning the file servers that hold the majority of files that people use?
Well, all we did was run the exe on the server via a remote desktop session out of hours to minimise any potential impact to the end users. We didn’t have to alter the offscan.ini as the options were perfectly fine, although we did of course have to create the directory where the files wouold be stored beforehand and then manually copy over when it was finished.
The process on the file server took a good deal of time to go through the terabytes of data, but eventually it did finish. Depending on how much data you house, you may want to just kick it off on a Friday and let it run as long as it needs to over the weekend.
So, now we have all our data all nicely presented on a network share.
Remember those other directories within the directory you extracted the orginal OMPM file contents too? Go on, it was only a little while ago, back in the time when Ipods were big. Let’s have a butchers as to what else is in that there folder:
Now of course we used the contents of the scan folder for the offscan running from the logon script but now we are going to use files from the Database and Report folders for this part.
Basically, the cab files are going to be imported into a SQL database of our choice and then we can use an Access front-end to read the files and give ourselves access to the data in a useful fashion.
So first off, we need to create that SQL database. Luckly we have a SQL 2005 Clustered instance for our needs without having to install an instance of SQL Server anywhere else so basically we’ll connect to that.
But we’re not going to able to create a database with the right table structure by ourselves. At this point Microsoft would say, fear not, as they do provide within the database folder a number of batch files with the relevant code to create the database with the required table structure for you. Not only that, this folder also contains the batch file used to import the collected data within the cab files into the database for you to use.
To create the database, you will need a command prompt open in the database folder and then we run the “createdb.bat” file with parameters for the SQL instance and the database name;
CreateDB.bat ComputerNameSQLInstanceName DatabaseName
Of course, if you have a default instance install, you only specify the computer name. So if all goes well at this point you should see something like the example below;
Now before the next bit, have a look at the machine you intend to run the import operation on. Just have a quick look at AddRemove Programs (or Programs and Features for Vista fans) to see you have SQLXML Service Pack 3 installed. If you don’t have it, you’ll need it installed before proceeding further.
Now we run the “importscans.bat” file with parameters for the sql instance, the database and now the path to all those log files that have been collected on the network share (you may want to map this as a drive to avoid any potential complications);
ImportScans.bat ComputerNameSQLInstanceName DatabaseName PathToLogFiles
so the example which best shows this in a way that makes sense is
ImportScans.bat ServerInstance OfficeScan Z:
Once you start this process, be prepared as this can take a long time to run…. maybe read War and Peace in the meantime…
It is also not uncommon – judging from when we ran this – for some issues with imports to occur. You may need to run it again if cab files appear in the root dir after you have run the import process.
All cab files that are imported successfully remain in a newly created folder called “OMPMImported” which is located in the area you have the cab files stored. If you want to reimport those, then move the cabs within that folder back to the root where you’re going to run the import from (in our examples, it’s Z:)
The thing is, errors displayed shouldn’t have a huge impact, unless it’s occuring for every single cab file. If it is you’ll need to stop this process, and see what could be causing issues such as connectivity to the database or problems with the files themselves. The importscan.bat does a good job of telling what the problem is so it’s shouldn’t be a huge issue to sort.
If you do need to re-run the scan process because you suspect the cab files are not as they should be, all you need do is change the scanid to a different number in the “Offscan.ini” file as shown from The Discovery Channel post.
Now the files have been imported into the database you will need to view the results. Now instead of running some SQL queries on a database structure you have no clue about, how about using Microsoft’s Access front-end, which is located under the Report folder back in that extracted area and is called “OMPM.accdr” (basically it’s the only access file of the two files in there)
You’re going to need Access installed for this file to work as it uses the application at run-time.
Once you launch the file, you may encounter a security notice appear (depending on your security set-up) about running the file in the first place as it could do naughty things to your machine. Just click open and you’ll be presented with this screen;
You’ll need to connect to the SQL instance and database that the data was imported into and then click connect. Basically if all goes well it will give the second stage which covers three areas;
These options will give you the report options to see what files have issues. Office 2007 compatilbity is the main option you’re going to use, but the other two options are good for looking up issues with Access databases out there and any errors encountered with the Office Scan process. So let’s go into the Office 2007 compatiblity option.
Basically the filter options are presented so you can narrow down the potential problems. If all you care about are the red highlighted files, which will have an issue, then you can select just the issues with the (red) in brackets by the description of the issue.
You can also narrow down by file extenstions, so you can just look at .doc files if you so choose. The options are there.
So when you click “Apply Filter”, the sql bits and bobs happen in the background, and then finally the other tabs are populated with number of files with a certain issue, what computers had the most files with problems, and what the files are.
Under the Issue Summary tab, there is an option called “Manage Issues” which will explain a bit better what the issues actually mean and what you can do about them, as illustrated below:
However with the links in the “Manage Issues” dialog, you may find that they are out of date and don’t actually go anywhere, so regretfully the best resource at this point is to dig deeper using our trusted friend, the one who keeps us warm at night: Google.
This tool will show you what you need to know in terms of what may occur. But in all honesty this is a part where you’ll need to decide about what you will want to look for and what issues are going to be important in the Office deployment.
Your management or indeed yourselves are going to need to either decide if the issues presented are going to be true issues or whether what’s listed is an acceptable risk and you should progress further anyway. What you need to do is to go through what is given back in terms of results and also then if required, work with the users to try and cut down the number of issues with the existing files.
How this is achieved with us, is that the list is passed onto the Desktop team managers and they will hammer out what they will consider to be acceptable as at the end of the day, it will be the Desktop teams that will recieve the most calls. After that, the process of contacting users will begin and hopefully, we should be in a better position when Office 2007 finally starts hitting the desktops early next year.
Join us again soon for another exciting episode of “It came from the great beyond!” (or something like that…)