Hmm..Really appreciate you have mentioned everything at once..

1. In the IIS Manager the Symantec Webserver should not be binded to any IP adress 

2. Login to SEPM - Policies - Policy Components- Management Server LIst -ADD ( add a new Management server list)
New Server the name of the server and port 8014 then IP address of the server and port 8014.

Assign this management server list to all your groups.

Then go to \program files (x86)\symantec\symantec endpoint protection manager\data\outbox\agent\(any alphanumeric folder\sylink.xml

Check if this sylink is showing the correct IPn Name and port.
Then replace this sylink on any one of the client

smc -stop ---replace sylink ---smc -start

Check if that makes any diffrence
Do a secars test on the client.
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007101711140148

Let us know if you are getting OK or any HTTP 401 or any error like this..

Wow! you have made lot of troubleshooting on this issue. 

The problem is with your IIS, the binding problem Before going to test the acutal issue we need to have your SEPM service running..

You dont get system dsn in 64bit box like others, the system dsn will be in different path.

How to work with Data Sources (ODBC) or ODBC connection in 64bit Windows OS

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008021900094548

fix this. and then do a repair of SEPM check if you are able to log in ...

in your IIS binding ,SEPM webiste should have acess to all, it should not be binded to one particular ip address.

Hello Vikram & Rafeeq,

Thank you for your replies

I've now unbound the SEPM website, so it's back to using the "All Unassigned" setting.

I've also found the 32bit ODBC app and found the "Symantec EndpointSecurityDSN", Rafeeq, can you give me more of a hint what you mean by "fix this", I've looked at so many different pages with suggestions in my own troubleshooting that I'm a bit confused by now. And by repair, do you mean a repair install?

Vikram, I'm no longer able to log into the SEPM Console, so I'll have to try your suggestions once I'm able to log in again.

/Laage

do a repair of SEPM
go to add /remove progams
select SEpM
do a repair.

once you do the repair, u should be able to log in..

once this is done we shall find why clients are not able to get the green dot..

OK, now we're cooking (or so I thought).

A repair install allowed me to access the SEPM Console once again.

I then added a Management Server List according to Vikram's guide and assigned it to all groups, or rather I assigned it to "My Company" and therefore to all underlying groups.

I had a look in "\program files (x86)\symantec\symantec endpoint protection manager\data\outbox\agent\(any alphanumeric folder)\sylink.xml" and instead of four "Server Address" tags I only had the following:
        <Server Address="[WIRED LAN IP-ADDRESS]" HttpPort="8014" HttpsVerifyCA="0" VerifySignatures="1"/>

Which is correct and what I used when I created the Management Server List above.

I then went to a client, stopped the SmcService service, went to "C:\Program Files\Symantec\Symantec Endpoint Protection", renamed the Sylink.xml file to Sylink.xml.org and copied the Sylink.xml from above into the client directory and finally i restarted the client with bated breath.
Alas, the client still sees the server as being Offline, I then tried to use the "Find Unmanaged Computers" tool to find the specific client and push a new installation to it that way.
Deployment status is shown as "Successful" in "Find Unmanaged Computers", but when I open the Endpoint Client on the client computer it is still the older version (11.0.4000.2295), rather than the version packaged with SEPM (11.0.4202.75).

Also, I previously imported two groups from our AD and the client computers there are listed, but the Logon Client and Description fields are blank.

Oh, and I'm still not able to access the SEPM Console remotely.

good that you are able to access the console..

now on the client, you need to run the secars test.. what vikram mentioned
on the client open a browser,
type

http://ip:port /secars/secars?hello,secars

if you are getting OK then its fine... let me know what you get..

If your windows firewall is enabled on your server, u need to create an exception for port 8014 or the port your SEPM is using in IIS

to test try disabling the firewall and check if client is communicating with manager. this should be the reason.

Now I'm embarrased; I never even gave a thought to the firewall. I was convinced that this DC was open to the domain. Mea culpa.

I started by opening the 8014 port and now I'm able to run the secars test and I got an OK from the browser on the client computer. I didn't immediately get a green dot on the Endpoint Client icon, but I tried stopping the SmcService and restarting it and lo an behold... a green dot, the server IP and Group appeared on the Troubleshooting -> Management tab and the client computer appeared with [USER NAME] in the Logon Client field in "SEPM Console".

Opening port 9090 and 8443 allowed me to access the SEPM Console remotely as well, though it complained about the Java version on my client. That is not really essential so I'll consider this solved.

A couple of follow up questions. The client computer still hasn't updated to the 4202.75 version. How do I push out the latest version of the software to a managed client?

I'm assuming the "Update Content" command updates definitions not the software version itself, am I correct?

I also tried installing two other client computers via the "Find Unmanaged Computers" tool, and again I get "Successful" in the Deployment Status field, but they still don't show up as managed clients in the group view of the SEPM Console, and I've tried refreshing the view a number of times. Will I really have to manually add/change the sylink.xml file on the clients?

 SEPm ADmin -Install Packages-Upgrade Groups with Package-Select the Latest Package-Select the groups you want to upgrade--Finish
Within couple of hours all your clients will be reporting 11.0.4202.xx

I thought I had it sorted, but things are still being weird here.

The original client is still showing the green dot, as is one other client. However most other clients seem to have problems connecting, ie. they are showing Server=Offline.
And when I look at their sylink.xml, it looks like this:

<?xml version='1.0' encoding='UTF-8' ?>
<ServerSettings DomainId="7C6968400A32025E01DF280BC7C27AE0"><CommConf><AgentCommunicationSetting AlwaysConnect="1" CommunicationMode="PUSH" DisableDownloadProfile="0" Kcs="F16EF463A5584040E00CC84D320F5C39" PullHeartbeatSeconds="300" UploadCmdStateHeartbeatSeconds="300" UploadLearnedApp="1" UploadLogHeartbeatSeconds="300" UploadOpStateHeartbeatSeconds="300"/><LogSetting SendingLogAllowed="1" MaxLogRecords="100" UploadSystemLog="1" UploadTrafficLog="1" UploadRawLog="1" UploadSecurityLog="1" UploadProcessLog="1"></LogSetting><RegisterClient/></CommConf></ServerSettings>

All smooshed together like this.

No server info and the two long alphanumeric strings do not match any of the names of the outbox\agent subfolders.

This is my "correct" Sylink.xml:

<?xml version="1.0" encoding="UTF-8"?>
<ServerSettings DomainId="A00410C20A020A0B012204AD5E6D7ED7" NameSpace="rpc">
  <CommConf>
    <AgentCommunicationSetting AlwaysConnect="1" CommunicationMode="PUSH" DisableDownloadProfile="0" Kcs="711EA8E950D0212BA667CEEEDB977C00" PushHeartbeatSeconds="300" RandomizationEnabled="1" RandomizationRange="300" UploadCmdStateHeartbeatSeconds="300" UploadLearnedApp="0" UploadLogHeartbeatSeconds="300" UploadOpStateHeartbeatSeconds="300"/>
    <ServerList Name="[SERVER NAME] Management">
      <ServerPriorityBlock Name="Priority1">
        <Server Address="[SERVER IP]" HttpPort="8014" HttpsVerifyCA="0" VerifySignatures="1"/>
      </ServerPriorityBlock>
    </ServerList>
    <ServerCertList>
      <Certificate Name="[SERVER NAME]">[10 LINES OF ALPHANUMERIC CODE]
</Certificate>
    </ServerCertList>
    <LogSetting MaxLogRecords="100" SendingLogAllowed="1" UploadProcessLog="1" UploadRawLog="1" UploadSecurityLog="1" UploadSystemLog="1" UploadTrafficLog="1"/>
  </CommConf>
</ServerSettings>

As you can see the Domain ID are different from the version on the client and there's no Certificate Name on the client version of the Sylink file.

I tried doing the secars test with this client and Internet Explorer didn't succeed, at first it just gave an unable to connect error and a refresh just had the little circle icon spinning, but nothing more happened.Firefox on the other hand reported OK without a hitch.

I'm able to ping the server no problem but even after disabling the firewall entirely on the server IE still won't succeed with the secars test.

I've attempted to replace the sylink.xml file, but the tamper-proof policy seems to be in effect, so I can halt the SmcService service, but when I try to disable the SMC process it is being instantly restarted. I was able to work around it by going in to safe mode and replacing the file, that worked and the computer is now displaying the green dot and showing up in the SEPM Console. That's not a realistic approach for 300+ laptops, though.

Good that its working, well the firewall was the culprit, i guessed it correct.
for replacing the sylink here is the procedure.

start - run --smc -stop
replace sylink

then smc -start.

now this gonna take lot of time if we are doing it manually, we do have a tool called sylink drop which does the things for u,

there is a small readme file read that and you should be good to go in replacing the sylink on all 300 in matter of few mins.

https://www-secure.symantec.com/connect/search?filters=type%3Adownload%20tid%3A691
 

Thanks Rafeeq,

The Sylink replacer seems to work. Now I'll just have to run it a couple of times during the week to catch all of the laptops floating around here 8-)

But I'm still wondering how come the newly deployed clients have this odd Sylink.xml, should they not be getting the correct Sylink.xml when I choose to deploy from the SEPM Console?

if you had any previous install, then you should check this option.

so that it can clear out old things.