Well I thought that I would post what my problem was and the fix in case it is of use to someone else.

 

I started by reading the documentation for SEP 11.X and decided doing an upgrade to the existing Version 10.X servers for me was not the best course of action.  So I loaded up a server with a clean copy of Windows 2003 R2 with SP2 and all other Microsoft updates.

 

The install of the server went smooth and no errors were reported.  After the install I did not run the migration wizard as I have plans to push this update out slowly first starting with new PC deployments and then existing machines.  So after the install I created Groups, Custom Settings, ,..etc... inside the SEP console.  After all that was done I then created the single .exe install packages to run on the clients.

 

Well this is were things got bad for me.  I took some test machines and run that .exe.  The install again went fine with no errors and after a short while the icon appeared in the tray next to the clock.  Well at first I thought yes it seems to be working correctly.  Well when I doubled clicked on the shield I noticed that it had not gotten the new group settings, virus patterns, ....etc... and the troubleshooting section showed the server status as Offline.

 

So I began some troubleshooting.  I made sure the desktop Windows XP with SP2 and all updates and firewall turned off could ping the server.  Then I made sure the server could ping the desktop.  After that I opened a browser and made sure it could hit the SEP server at the correct web address I got the normal Page Under Construction so that told me that was ok.

 

I also opened a ticket with Symantec and was provided the Sylink.exe tool.  I used this tool to look at the client to server communications and saw that the IIS web server was generating a 400 error which means bad request when the client went to check in with the server.  The Tech had me try the Sylink Drop tool but that had no effect so he was going to research it and call me back.

 

While I was waiting I began that task of trying every configuration option I could from a complete scrubbing of SEP and reinstalling.  Trying Windows 2003 R2 plain, with SP1, and SP2.  Then I thought that maybe it just does not like Windows 2003 server so I reloaded the box with Windows XP Pro With SP2 and all updates.  While I was at it I also tried the migration wizard since all of my other attempts I skipped this part and did them manually I figured why not try it.  Well I launched the wizard right after the SEP console install and had it create the groups and .exe install packages.  After I had the packages I installed one of them on a test PC and what do you know I got the green dot finally and the client and server were talking to each other.  I could issue commands to the test PC from the SEP console and everything I was so happy.

 

So at this point I thought maybe it was because I had used the migration wizard to create the install packages and SEP groups.  At first I thought it might have been because I was using XP but thought about it and said it cannot be a problem with Windows 2003 R2 because I tried plain, SP1, and SP2 and if it was I'm sure Symantec would have gotten a lot of calls.  So the next day I tore the machine down again loaded Windows Server 2003 R2 With SP2 and all updates only this time I did as I had done on the Windows XP install and used the migration wizard to create the install packages and groups in the SEP console.  I ran the package install on a clean test pc just as I had done earlier and expected to see the same good result.  Well I did not instead I saw what I had seen so many times before the client could not get updates from the server.

 

At this point I was out of ideals and was thinking ok then I guess my SEP consoles will need to be Windows XP then.  But I did not like this option due to the connection limits that Windows XP has.  So I thought for a bit about anything else that I may have done differently when I did the SEP console install on XP.  Then it hit me I had installed this SEP console so many times that I was tired of retyping my passwords over and over again so on the XP install of SEP console for the client to server password I had made it a short password of only 4 characters.

 

Well after remembering this I ran clean wipe on the server to once again remove SEP console.  On the reinstall of the SEP console using the Windows 2003 R2 With SP2 I once again used a basic 4 character password for the client to server communications.  After the install finished I did not run the migration wizard I instead opened the console and created my groups, custom settings...etc... and then made once again a .exe install package.

 

After I had the .exe install package I ran the clean wipe utility on the test PC to remove the SEP client rebooted and then ran the new install package.  Well what do you know after the install I got the green dot and the client was talking to the server.

 

I also ran the Sylink.exe to look at the traffic ad was no longer getting an IIS 400 error for the SEP console server.

 

So to recap it was not the OS or the service pack or having the migration wizard create the groups or packages.  It was the password I was using for the client to server communications.  My theory is that if the password for the client to server communication is to long or to complex when the client goes to configure the hash value that it uses in the URL request it becomes to long and the IIS web server cannot process the URL request resulting in my 400 Bad Request errors.

 

Bill