For whatever reason, it’s quite possible to end up with a Symantec AntiVirus client which isn’t talking to the server – You may have accidentally uninstalled Symantec AV from you’re server, reinstalled the server or moved it on to another server. So how do you get those SAV clients to re-register in the console?

Well, I decided to use a logon script to sort out a number of clients in one hit. Download the following av-fix batch file:

Download: av-fix.bat

In the case of SBS 2003 – you need to place this file in the netlogon folder. Once in place, open up the file and place your Symantec server name in the correct place, replacing “\\yourserver”.

To make the logon script silent, I decided to use a small program called hstart. Download it from here and place in the netlogon folder. My script uses the widely available robocopy, so get yourself a copy of that and place it in the same folder.

Now, from your main logon batch script you just need to insert the following line:

hstart /NOCONSOLE “av-fix.bat”

This executes the batch file in hidden mode (the user won’t notice anything)

The av-fix.bat file places a grc.dat in the correct place on your client machines. It also updates the pki directory.

It’s tested to work on XP (but I’m unsure about Vista…)

Sit back and watch the Symantec Console repopulate as the clients login. Beautiful! I hope you find it useful!

Update: I’ve discovered that Outlook 2007 works fine if you switch the networking options in virtualbox from “NAT” to “Bridged”. It also fixed some other issues I was having (mapped network drives and group policy didn’t get applied. For reference the domain controller is a Windows 2008 SBS server.

w32tm /config /syncfromflags:MANUAL /manualpeerlist:time.nist.gov
w32tm /config /update

Obviously you can use your preferred time server instead of time.nist.gov, but run these two commands and wait a few minutes, and you should see your clock correct itself. The process will show ‘time-service’ events in the system event log to confirm your changes.

The application stops due to an unforeseen situation, for example an error in the database.

It turns out that the application tries to write to various files that are installed in Program Files, which of course normal users do not have access to. Obviously giving the entire userbase rights to modify things in this way was out of the question, so we decided to try some other methods. We have a ’software’ share on one of the servers for software that can be run directly from an installation directory, so we tried that. The same problem existed, as users were still not able to write to the install directory.

In the end, our solution was to create a new share, to which users have write (update) access, as we did not want to compromise the existing software setup, when everything was running smoothly. Once we had shared the software in a user writable directory (and published it in the form of a shortcut on the default desktop), everything worked!

It would be nice to see an update to the software to allow it to run without administrator rights, as I am sure there are situtations where a solution like ours would not be feasible.

Update 24/03/2009:
We have found that although this solves the problem of running the software, it does not allow you to run more than one instance at a time – useless for a network application like this one. The software must be putting a lock on its files, very annoying!

To deploy this via group policy, you will need to use a startup script, as it is not possible to extract an MSI to use with the usual method. However it’s a really simple script so should be no problem to get it up and running.

Just share the installer executable somewhere on your server (we usually have a shared software directory for this purpose), and add the following to a startup script (replacing the path with the correct one for your situation, of course)…

“\\SVR\Software\PhotoScapeInstall\setup.exe” /S

Note the upper-case S in the switch – it will not function with a lower-case S. This will install desktop and quick-launch shortcuts, which unfortunately there seems to be no way around. However, a good point is that it does not install Google Toolbar, which is an option selected by default if you use the wizard install.

Have fun!

If you are using a stand-alone computer or if you want to enable verbose status messages on only one computer, follow these steps:

1. Click Start, and then click Run.
2. In the Open box, type gpedit.msc, and then click OK.
3. Expand Computer Configuration, expand Administrative Templates, and then click System.
4. In the right pane, double-click Verbose vs normal status messages.
5. Click Enabled, and then click OK.
6. Close Group Policy Object Editor, and then click OK.

Run a gpupdate /force if you can. After doing this, we noticed our machines were hanging at the printers group policy. After disabling the offending printer policy, logon worked fine again. As techies we decided to leave Verbose Status Messages switched on, as it can actually be very useful. Check out Chris’s previous post for more on our printer issues.

Server Error in ‘/’ Application.

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: Unrecognized configuration section ‘connectionStrings’

Source Error:

Line 20: Line 21: </appSettings> Line 22: <connectionStrings>

Source File: D:\home\Default\website.com\htdocs\web.config Line: 22

Version Information: Microsoft .NET Framework Version:1.1.4322.2379; ASP.NET Version:1.1.4322.2379

Well, it turns out this is what happens if you try and run an ASP.NET 2.0 application using ASP.NET 1.1. So just follow these quick steps to cure the problem:

1. Click Start
2. Click Run
3. Type inetmgr (or open the IIS manager from the admin tools)
4. Expand the server object
5. Expand Default Websites
6. Select your website, eg website.com
7. Right click and go to Properties
8. Select ASP.Net Tab
9. ASP.Net version select version 2

If this option isn’t available make sure you have the dotnet framework 2.0 installed. Problem solved!

\\SVR\Share\Path\setup.exe /quiet

That’s it! It installs near instantaneously on newer machines as well – well done that man.

When connecting a computer via the SBS connection wizard (found at the URL http://connect) by default, we found that when the _sbs_netsetup user logs on, that it does not log off again, and any attempt to log off manually just causes it to automatically log back on.

To solve this we needed to grant local administrator rights to the local user _sbs_netsetup. Obviously as the user is currently logged on and you cannot log off in order to log back on as an administrator, it is not possible to do this on the local machine. To do this, follow these steps:

1. Run MMC on your server
2. Add computer management snap-in and set it to manage the computer in question
3. Browse to Local Users and Groups / Users
4. Add _sbs_netsetup to the Administrators group
5. Log off the local machine

Now the SBS setup process should complete as normal and you should end up with a machine connected to your domain and ready to go!

The user ‘HP LaserJet 2300 Series PCL 6′ preference item in the ‘Common {<id>}’ Group Policy object did not apply because it failed with error code ‘0×8000ffff Catastrophic failure’ This error was suppressed.

This error is not very helpful as you can see, and infact turned out to be that the driver for the printer was not available. This led us into another issue – that of installing x86 drivers on the server to be available for clients when they connect.

Initially, we thought this would be easy. “Oh, just go into sharing and tick the x86 box in additional drivers”, we thought. Having tried to do that it turned out to be a lot more complex than it should be. Ticking this box will ask you to browse to find the x86 version of the x64 driver you currently have installed – easy. Then it will ask you to ‘please provide path to windows media (x86 processor)’ – OK, that’s doable?

It seems to be looking for the file ntprint.inf, and wanted to look on a CD-ROM, in the I386 folder by default. So, recognising the folder name we stuck in the XP pro disc, thinking we would be off, but alas, it tries to load the file and then gives the same prompt again! I then decided to search my own workstation (Vista Ultimate x86) for the the file and found the following directory to contain it, as well as an I386 folder.

C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_xxxxxx

I copied the contents of this directory to the same directory on the server which holds the x86 version of the driver in question, and then went into sharing and ticked the x86 box once more. It again asked for the path to the driver, but this time did not prompt asking for the additional media!

So, in conclusion, it seems you need both your x64 server and an x86 client available in order to get the driver installed, for our printer at least.