For SysAds: What to Do About Those .PST Files?

If you want to see a topic that IT folks really get into heated debate about, Google the search phrase "network PST". PST files -- those huge files that Microsoft Outlook creates locally on workstations to store/archive just about anything from email to contacts to tasks -- are a system administrator's nightmare. Stored locally on each user's C: drive, they almost never get backed up to tape. Essentially unseen by everyone (including the user), they can grow to gargantuan size. And without being part of the user's roaming profile, they don't transfer when a user receives a new PC.

Originally, I thought that the best practice was to redirect all PST files to a server location, preferably a folder eponymous with the username. The rationale was that by keeping all the PST files on a server, they could both be backed up and kept in-check. However, the more research I do, the more I think this server-side PST file idea is a bad one. For starters, here's Microsoft's stance on this practice:

http://support.microsoft.com/kb/297019/en-us

Here's one article that talks about why server-based PSTs are a bad practice:

http://blogs.technet.com/askperf/archive/2007/01/21/network-stored-pst-files-don-t-do-it.aspx

Granted, they're talking about huge (multi-GB) PSTs being pulled by hundreds of clients simultaneously, which is not the case with our network. (No user appears to have a PST file larger than 700 MB, and nearly all PST files are under 100 MB.)

However, I'm still concerned about the possibility for data corruption and server downtime.

There are a lot of alternate solutions being debated on all these tech blogs, but two easy ones that make sense for us stick out in my mind:

1. Continue to use the server as a PST store, but only as a backup.

Have the users write to their PST files locally, then have a logoff script upload the PST files at the end of the work day. No more worries of data corruption and server bandwidth problems, but we can still see how big everyone's PST files are and maintain a backup of them should any of the workstation hard drives crash.

2. Standardize/lock down the AutoArchive function of Outlook via GPO.

Here's how: http://office.microsoft.com/en-us/ork2003/HA011402861033.aspx (Most users have no idea what the heck they're agreeing to when the AutoArchive dialog box pops up.) Doing this, you can also set up a Retention Policy, which is disabled by default if you go to your Outlook settings and look at the bottom of the AutoArchive dialog box:




This is the PST backup script that I created:

@echo off
cls
echo This script will copy all OST and PST files
echo from your C: drive to M:\Outlook_Backup.
echo Please exit from Microsoft Outlook before continuing.
echo ----------------------------------------------------------
pause
echo.
md M:\Outlook_Backup
cd "%USERPROFILE%\Local Settings\Application Data\Microsoft\Outlook"
copy *.* M:\Outlook_Backup\
pause

For SysAds: When Workstations Can't Connect to the Domain

Sometimes, for reasons not readily apparent, a client PC will "drop off" the domain. You'll know this because suddenly, no user will be able to log into the domain from that PC even though the NIC is active and the computer has unfettered connectivity to the switch.

When trying to join a computer to the domain, simply log onto the machine using a Local Admin account, right click on My Computer, select Properties, select the Computer Name tab, click the Change button, and retype the name of your domain in the Domain text box. Click OK twice and it will ask you to reboot this particular workstation. If you are unable to change the Domain name, an alternative solution is to switch the computer to Workgroup mode (in this same dialog box), reboot it, then switch it back to Domain mode again. In either case, the PC should now reappear in Active Directory.

The only problem is that it may not appear in the Computers bucket in Active Directory -- often times it won't be there even though it should be.

If this happens, run a search on it. Change "Users, Contacts, and Groups" to "Computers". Change the In: field to "Entire Directory". You may have to leave the Computer name: field blank and scroll through all the search results.

The computer will be found by this search even though you won't be able to find it yourself by searching through all the Active Directory buckets!

Now, you just have to right-click on that computer in the search results and select Move... . Select the bucket that this computer should go into and click OK. Now, even though you couldn't see it before, it will magically appear in the bucket you chose!

For SysAds: Symantec Antivirus Clients Not Pointing to Correct Server

Migrating clients from one Symantec Antivirus Server to another can sometimes leave certain clients "orphaned" without a server to manage them. Comparing the list of clients you see in Symantec System Center Console up against your actual workstation inventory can go a long way towards identifying which machines aren't pointed at the current Symantec server.

One way to repoint orphaned clients is to use the ClientRemote Install feature of Symantec System Center Console. If the Console can see the workstation and the workstation has Remote Desktop enabled, you an remotely upgrade its AV software and simultaneously point it to the correct server.

However, not all workstations fit this criteria. So I wrote a short script that will fix the problem at startup on select machines. You will need to create a tiny marker file on your server called "sym_serv.txt" that flags the PCs that this script has run on. Here's the script:

@echo off
IF EXIST C:\sym_serv.txt GOTO End
cls
echo Windows needs to update your Symantec Antivirus client software.

copy "\\SERVERNAME\c$\Program Files\SAV\GRC.DAT" "C:\Documents and Settings\All Users\Application Data\Symantec\Symantec AntiVirus Corporate Edition\7.5\GRC.DAT"
IF ERRORLEVEL 0 copy \\SERVERNAME\dfsfiles\Symantec_Server\sym_serv.txt c:\
:End
pause

It's pretty straightforward: it checks for the marker file to make sure this doesn't get done more than once. If no marker, then it copies the GRC.DAT file fresh off the Symantec server into the appropriate local folder. Then it creates the marker file if successful.

I'd recommend creating a separate OU with its own GPO that runs this script at startup. Then you can target just the orphaned workstations.

For SysAds: Deploying Adobe Reader 8 as a Managed App, Part 2

So here is the formal step-by-step I created for setting up Adobe Reader 8 as a Managed Application. See the following PDF manual (ironic as that sounds) for additional information: http://www.adobe.com/devnet/acrobat/pdfs/gpo_ad_8.pdf

Go to the Adobe site to download the installer:
http://www.adobe.com/products/acrobat/readstep2_servefile.html?option=full&order=1&type=&language=English&platform=WinXPSP2&esdcanbeused=1&esdcanhandle=1&hasjavascript=1&getsconly=1&x=76&y=25

This installer EXE file is small. When you run it, it downloads the actual Adobe Reader 8 EXE file. Save the large (~21 MB) Adobe Reader 8 EXE file to your desktop -- don't run it.

Now it would be best to create a shared folder on a commonly-accessible network drive that will hold all of the Adobe Reader 8 installation files that you are about to create. This folder is referred to by Adobe as the “distribution point”.

This next step is small but important! Once you make this folder, right-click on it and select Properties. Now select the Security tab. Add the security group “Domain Computers” to this list. If you don’t, none of the client workstations will have the rights to access the installation files.

Then follow the directions on this obscure knowledge base article to create an MSI file from this EXE file: http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=kb400540

I tried it and it works: it creates the MSI. But here’s the thing: you can’t push this MSI out to clients. According to another document that Adobe put out, you have to do an "administrative installation" of that MSI first. To do this, you have to do a Start / Run and type in:

Msiexec /a \\INSERT PATH
HERE\AcroPro.msi

Then when it asks you where you want to install the files, you need to tell it to install the files into your distribution point.

Now that you’ve got the distribution point all set up, you will want to customize the your client-side version of Adobe Reader 8. This step is optional, but skipping it might lead to a large amount of user-induced pain. To customize, use the Adobe Customization Wizard, which can be downloaded here:

http://www.adobe.com/support/downloads/detail.jsp?ftpID=3564

Once you’ve downloaded and installed the Adobe Customization Wizard, run it and open up the MSI file in your distribution point. Here are some changes that I recommend:

- Under Personalization Options, set Installation Path to your distribution point path
- Under Installation Options, select Run Installation Silently and Suppress Reboot
- Under Shortcuts, uncheck the worthless Desktop shortcut
- Under EULA and Online Features, check Suppress display of End User License Agreement (EULA), check Disable all updates, and check In Adobe Reader, disable Help > Purchase Adobe Acrobat
- Under Toolbars and Document Status, check Do not show Beyond Reader at startup and
check Disable Adobe Online Services

Once you’ve set up Adobe Reader 8 the way you want it set up, click Save and it will prompt you for a location to save an MST file. Save this MST file in your distribution point. This file contains all the changes you just made.

If you get an error message when you save this MST file, it’s because the admin installer utility forgot to put a file called ‘setup.ini’ into the distribution point folder that contains the MSI file. You will have to create it and put into your distribution point if you need it. The file should look like this:

[Startup]

RequireOS=Windows 2000

RequireMSI=3.0

RequireIE=6.0.2600.0

CmdLine=/sall /rs

[Product]

msi=AcroRead.msi

CmdLine=TRANSFORMS="AcroRead.mst"

[Windows 2000]

PlatformID=2

MajorVersion=5

ServicePackMajor=4

[MSI
Updater]

Path=http://ardownload.adobe.com/pub/adobe/reader/win/8.x/8.0/misc/WindowsInstaller-KB893803-v2-x86.exe

Now you’re ready to create a GPO in Group Policy Management. Right-click on the appropriate OU and select Create and Link a GPO Here… . Name your new GPO and hit Enter.

Right-click on your new GPO and select Edit… . Go to Computer Configuration / Software Settings / Software installation. Right-click in the right-hand pane and select New / Package… .

Browse to the MSI file in your distribution point and click Open. Now select Advanced and click OK.

Under the Deployment tab, select Assigned. Leave “Uninstall this application when it falls out of the scope of management” unchecked.

Under the Modifications tab, click the Add… button. Now browse for the MST file that you created in steps 7-9 (it should be in your distribution point).

Click Apply, then click OK.

Now a couple more edits need to be made to this GPO within the Group Policy editor. Go to Computer Configuration / Administrative Templates / Windows Components / Windows Installer.

Double-click Always install with elevated privileges, change to Enabled, then Apply and click OK.

Double-click Logging, change to Enabled, and in the text box, type iweaprcv and click Apply then OK.

Your GPO is now live, so you may want to unlink it at this time…particularly because we still have to tackle the workstations that still have Adobe Reader 5 installed.

Don't forget about the short script thtat checks a PC to see if Adobe Reader 5 is installed, and if so, uninstalls it from that PC. You will create another GPO that runs this script at startup on
all your client workstations.

Save this script into your distribution point. Then create a new GPO like
you did in step 10.

Right-click on your new GPO and select “Edit…”. Go to Computer Configuration / Windows Settings / Scripts / Startup. Click the Add… button. Browse to your script file and click Open, then OK. Click Apply, then click OK.

Now your Adobe Reader 5 removal GPO is live. If both of these GPOs are live, then when a client in the OU restarts, first Reader 8 will get pushed to the client, then any existing version of Reader 5 will be uninstalled. Unfortunately, I have found through testing that doing these two actions in this order is problematic: the uninstall ends up messing up a small part of the Reader 8 installation. So my recommendation is to first turn on just the Reader 5 GPO and let it remove Reader 5 from your client workstations for several days. Then once all or most of your workstations are clear of Reader 5, turn on the Reader 8 push.

If, in spite of your efforts, the Reader 5 removal happens after the Reader 8 push on a particular workstation, one of two things might happen:

a) When launching Reader 8 for the first time, Windows has to rebuild some of the application files for Reader 8 that got deleted by the uninstall. This process can take as much as 10-15 minutes, but it seems to work.
b) The file association for PDF gets somehow zapped by the uninstall. The user would have to
know or be assisted to re-associate PDF with Adobe Reader 8.

Good luck!

For SysAds: Deploying Adobe Reader 8 as a Managed App, Part 1

Few are brave enough to attempt to deploy Adobe Reader across an enterprise network as a managed application. Recently, I discovered why -- Adobe doesn't make this easy! The process is kind of complicated and I had to pull info from multiple sources to figure out the best way to do it. In the next two posts, I will show you how to actually deploy Adobe Reader 8 as a managed application through Active Directory.

Part 2 of this blog post is a step-by-step procedure for setting up Adobe Reader as a managed application for you to implement at your discretion. We've tested it thoroughly here and are now pushing out Reader 8 to the whole building. In this post, I'll give you the background information for the deployment.

The key obstacle in this process is that Adobe Reader has a history of installing itself as a new version without deleting previous versions off the PC, leaving multiple versions of Adobe Reader fully-installed.

Here were the conclusions from our testing:

- Installing Adobe Reader 8 automatically uninstalls versions 6 and/or 7
- Installing Adobe Reader 7 automatically uninstalls version 6
- It seems that no version of Adobe automatically uninstalls version 5
- The push will not work on any machine that doesn't have WinXP Service Pack 2

So to handle the machines that still have residual Adobe Reader 5 on them, I created a startup script (remove5.cmd) using a line of code I found on a tech blog (http://www.stealthpuppy.com/blogs/travelling/archive/2007/03/12/uninstalling-adobe-reader.aspx). The script checks for Adobe Reader 5 first, and if it exists, it does the uninstall.

This is the script:

IF EXIST "c:\Program Files\Common
Files\Adobe\Acrobat 5.0\NT\Uninst.isu" GOTO Uninstall

GOTO End

:Uninstall

C:\WINDOWS\ISUNINST.EXE -y -x -f"C:\Program
Files\Common Files\Adobe\Acrobat 5.0\NT\Uninst.isu" -c"C:\Program Files\Common
Files\Adobe\Acrobat 5.0\NT\Uninst.dll"

:End

This script worked on all 3 test computers that had Reader 5 installed. However, there were a couple of minor side effects:

- On two of the machines, after uninstalling Reader 5, when launching Reader 8 for the first time, Windows had to rebuild some of the application files for Reader 8 that must have been deleted by the uninstall. This process took about 10-15 minutes.

- On the other machine, no rebuild occurred, but the file association for PDF was somehow zapped by the uninstall. The user would have to know or be assisted to reassociate PDF with Adobe Reader 8.

It's up to you what order in which these two things happen:

- Adobe Reader 8 push
- Adobe Reader 5 removal startup script

Removing Reader 5 before pushing Reader 8 would eliminate the uninstall issues, but in some rare cases it could leave some clients without Adobe Reader at all (if the push fails). Your call...