SEPM 12.1.3 using wrong NICs on servers

[rmoc]

I upgraded to 12.1.3 on the server with Symantec for SEPM and the client SEP on that server.  Nearly all the user machines are on SEP.

Servers, except for the one with Symantec SEPM, are still on 12.1.2015.  Those will be upgraded on the next update/reboot cycle sometime soon.

 

I noticed two new issues.

SEPM isn't recognizing the server its on.  The ip address listed is for its backup network NIC.

Some of the other servers are recognized, but they list the backup network NIC for them too.

 

I found this post.

http://www.symantec.com/business/support/index?page=content&id=TECH169379

Everything's greyed out in that policy box though.  I can't change anything.  I am logged in on my admin account on SEPM.

 

I did an nslookup from the SEPM server on itself.  It gives me back ipv6 results.  I wonder if that's the issue.

Otherwise I was thinking of removing the backup NIC ip address from the policies box.  I'm not sure if that's a great idea though.

 

SEPM is recognizing the client machines.  I see green lights.  Looks like they got updates.  It looks like it's working, but the wrong ip addresses concerns me.

[pete]

create a new MSL and assign to the test group and monitor.

[rmoc]

Hm.  I'm desktop support.

What's an MSL?  And how do I create a new one?

[rmoc]

Managed Server List.  I see.  I thought it was something with a server NIC.

 

Still looking how the MSL is connected to a policy...

 

[pete]

MSL will list all the NIC IP, hence no drop of the clients

[rmoc]

I'm not quite following....

 

In SEPM I've got four entries under priority 1.  the regular ip address, the backup ip, name of server, and fully qualified name of server.

Why is it all greyed out?  Why I can't change those?  I was thinking I could make a priority 2 branch and move the backup ip address to that.

 

Or is it an ipv6 thing and I should disable ipv6 on this server? 

[rmoc]

I tried disabling ipv6 on that server.

http://support.microsoft.com/kb/929852

 

It now pings itself with ipv4 instead of 6.

 

No change in SEPM though.  It still sees itself as offline, still has backup network ip address (ipv4) listed for itself and a few other servers.

 

I did an ipconfig /flushdns on it too.  No change.

[rmoc]

I made a new managed server list (policy button, expand policy components down, management server lists).  I added the name, ipv4 address, and fully qualified name there (no backup network ip address).

Then I went to the client list, policy tab, communication settings, and changed the management server list to my new list. 

I tried refreshing, no change.  I'm waiting for the heartbeat to sync up.  Or I could tell them all to update their policies....  Or restart the server again.

[rmoc]

Ah, cool.  All but the SEPM server have the correct ip addresses now.  The heartbeat must have sync'd them.

 

Why doesn't SEPM recognize itself?  It's still listing itself as the backup network ip.

[rmoc]

Restarted the SEPM server again.  Some progress.  It recognizes that the server is on.

Before the restart, the SEP client software on the SEPM server was up-to-update.  I watched it pull down and install updates on itself.  So it was connecting.  It just wasn't recognized by SEPM.

It still lists the backup network for the ip address.  I'm waiting to see if the heartbeat with fix that.  From SEPM I told it to update content (if that updates policies) and I went on the client SEP and told it to update policy.

[rmoc]

Weird.  It's been over 30 minutes.  No change. 

Looks like it's all working.  SEPM just lists itself in the client list as using the backup network ip address.  Yet it's sitting in the same folder, same policies, as the other servers who are now on their correct ip address.  That's after restarting the SEPM server. 

I did another SEPM client update, SEP policy update but that probably won't change anything.

[rmoc]

Good news.  Checked in on the SEPM server just now.  Ip address is correct.  It's not using the backup network ip address anymore.  I didn't do anything extra.  The policy update from Friday must have finally taken effect.