Hello again dear CW Blog readers, it’s been almost a year since the initial series of posts describing a automated method of deploying Office 2007 via your KIX-Based logon scripts, complete with additional items of interest surrounding the customisation of the Office Ribbon itself to allow you to call your own programs or functions for easier use of the product itself.
Now you thought that would be it on the matter, but of course as with all things, there can be room for improving the process itself.
The KIX method we used before assumed that the user running the logon script was an administrator of the machine, and of course provided not a lot of feedback to the user in terms of what the process was doing at the time.
There was also the point of not enough redundancy within the script itself to take into account certain issues like disk space, and what about informing the end user that a certain part failed and they needed to inform their helpdesk as to what failed?
What about having the option of specifying what server to run the install from for multiple locations and packaging the office folder content to be copied to any server and know that all will be well?
Well I had thought about this myself during the initial push of the software, when the original Computer Weekly content was being created last year and while out on site performing this very task, I came across this:
Using this free tool can present you with new options for not just deploying software with Admin Rights, but also automating installations that normally cannot be automated by working through the installer that a given program gives you.
One example of this in the past has been Lotus Notes, where writing a InstallShield answer file seems to fail more than it succeeds. For the purposes of this however, we will be transplanting a lot of what we did in the original KIX to AutoIT’s syntax.
The complete files for the AutoIT will be included here for you to download and use as you see fit, however, instead of going through the script in great details, here are the finer points of what they will do.
Both use similar variables as shown below
$Officefilelocation = “\” & $CMDLINE
$username = “YourAdministratorUsernameHere”
$password = “YourPasswordHere”
$DoNotProceed = “Proceed”
$file = FileOpen(@MyDocumentsDir & “OfficeInstall.txt”, 1)
The username and password variables are where you enter a username and password of a user that has full local administrator access to your workstations, but also the relevant NTFS permissions to the share where you will place your Office installation files, so it has to be a domain user for the script to work as is.
You must decide on what user account to use here as of course, it is a potential security issue therefore all due consideration is required as what will work best for you.
The RunAsWait command features heavily in the scripts as you can see here from the Office Cache Auto IT Script:
RunAsWait($username, “YourDomainNamehere”, $password, 0, ‘C:WindowsSystem32cmd.exe /c %windir%System32reg.exe ADD HKLMSOFTWAREOffice2007InstallForMyCompanyOfficeRollout /v OfficeCached /t REG_SZ /d “NoDiskSpace” /f’)
Here we are calling Reg.exe to add a key to the HKEY_LOCAL_MACHINE area, where by default, normal users have no write access to. However, we can use this command to run the reg.exe as a user with local admin access, the username and password are the variables you populate at the beginning of the script and the “YourDomainNameHere” part specifies what domain the user is on, for example, say DOMAIN is the name of your Active Directory. The AD short name which we have, DOMAIN should be used here, instead of the other method of DC=”DOMAIN”,DC=”COMPANY”,DC=”COM” that AD administrators are familiar with these days.
You could if you wish put the domain name in a variable at the beginning and then call that from the RunAsWait command like:
RunAsWait($username, $Domain, $password, etc
(Yes, you could argue I should have done that myself! I always think of things after it’s done…doh!)
Office Cache script:
Basically this entire part of the script will do the caching to the local machine just like before, except it’s running as the Admin user and also ensuring there is enough disk space to do so, if there isn’t it will inform the user and based on what is in the script, either you can run another script to log the problem computer or do nothing.
Office Install script:
Here we will actually achieve mostly what was set out before, we run the office install from the local machine, still referencing the MSP file which was created using the Office Customization Wizard and the xml config file mentioned in this series before. We will also be installing the additional items, once again, just like before.
The difference with this version of the script, just like the caching script, we are using a different user to run the programs, write to the registry and informing the user at what stage of the install we are at, where possible.
The AutoIT scripts will allow you also to name what server the install files reside on, and as long as the file structure remains the same as well as the NTFS permissions to the share with the Office Install files, you will be fine.
Now hold on a moment, I hear you cry! That sounds all fine and dandy…But how do we use these scripts from AutoIT without having to install anything extra on workstations or leave our passwords contained in these for the casual passerby to look through? Also how do we can pass in a server name for the office share?
Well thankfully, we have at our disposal, also included with the free installation of AutoIT, a simple script to exe converter:
Because we are calling these exes later from a KIX script it would be ideal to ensure that the console option is ticked.
The way it works, you select your script to start with and then specify the name of the exe you want to create (It may be better to call it something that’s only one word like OfficeInstall.exe for example) When you have created your exe, you should see something like this:
The way to use this exe then in order to pass-through the name of the server you want to point to would be simply this from your KIX script:
Shell ‘\serverShareMyShinyNewProgram.exe ServerName’
That’s it basically.
This is captured into a variable under each exe as shown here:
$Officefilelocation = “\” & $CMDLINE
Under AutoIt, the $CMDLINE signifies that the first parameter is passed through will be the one that is given to this variable, with our script having two slashes at the front, so the end result if we passed servername through would be: \servername and therefore gives us the start of our network locations for the rest of the scripts being run from the executables.
This functionality of course can be extended further, but for our purposes here, this is enough. All this serves to cut down the content of the KIX side of the logon scripts a great deal and in the end we end up with something like this:
(to save on space, in this example I’ve left out calling the VSTO installers as that has not changed from the older deployment KIX script)
;************* This Part of the Script will contain the Office 2007 deployment script text *************** ;** This will run before the rest of the script on normal machines to avoid issues as much as possible **
? “Running Job for Office 2007 preparation”
? “Please be patient, this may take some time…”
Select Case InGroup(“Office2007CacheOnly “)
? “You are a member of the Office 2007 Cache Group”
$officecache = “1”
Case InGroup(“Office2007Group1 “)
? “You are a member of the Office 2007 Rollout Group 1”
$officeinstall = “1”
$officecache = “1”
Case InGroup(“Office2007Group2 “)
? “You are a member of the Office 2007 Rollout Group 2”
$officeinstall = “1”
$officecache = “1”
$officeinstall = “0”
? “You will not have office installed at present”
? “*********** Copying Office 2007 Install Files *************”
;Calling brand new AutoIT exes instead of all that nonsense before!
if $officecache = “1”
Shell \ServerOfficeRollout$OfficeCache.exe SERVERNAME
“***** Checking Disk Space Setting in Registry *****”
;Not only are we checking for disk space in the AutoIT exes, we also do it here as a precaution
$DiskSpace = ReadValue(“HKEY_LOCAL_MACHINESoftwareOffice2007InstallForMyCompanyOfficeRollout”,”OfficeCached”) if $DiskSpace = “NoDiskSpace”
? “Exiting Office Install Script due to low Disk Space”
? “***** Run Office Install if allowed here ******”
;This part will begin the office install if the above officeinstall variable is set to one
if $officeinstall = “1”
Shell \ServerOfficeRollout$OfficeInstall.exe SERVERNAME
;Insert part for VSTOs here if you want them
And that is it.
When the exe is running, you can tell from the Windows Taskbar what exe is running as it pops up there and if you hover your mouse over the icon, the name of the exe appears.
Here are the two files to use with AutoIT:
CWAutoITOfficeCacheScript.au3 (Office Cache Script)
CWAutoITOfficeInstallScript.au3 (Office Install Script)
So really, with this improved method, not only will you gotten around the Admin install issue, but you have executables that can be tweaked as you want, and your actual KIX logon script becomes a lot simpler to read through.
In terms of whether or not it works better for you in your environment, of course it will need testing, in terms of success rates when I applied it, it was a lot more encouraging to say the least.
Because you can’t have enough information on certain parts of the process, here are some links here for reference on how to use the reg.exe and the AutoIT software as it’s an entire series of tutorials by itself.
Also remember the previous posts for the Office deployment cover the issues of creating a customised Office installation as well as customising the Office Ribbon and going through what content needs to be included in order for a silent install of the Ribbons to take place.
Once again, any and all questions, please leave a comment here or a message on my twitter feed and I’ll be more than happy to help.
Until next time!