Endpoint Protection

We want to create a clean SEPM 12.1 install (fresh database, no legacy information needed)
We still want our exisiting ~500 SEP clients to check in and comunicate with this new server.

What steps are neccessary to ensure comunication?

We want to avoid as many legacy settings getting imported as possible.

Regards,
Thomas Brewster

follow this article except the restoring of database.

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

the certificates needs to be restored for client to communicate back with the new SEPM.

Those are the directions I've followed, but I'm not having any luck getting clients to communicate.
The certificate has been restored and the mangement server list contains both the new and the old servers.  I shut off the old server's SEPM service and the clients will not check in with the new server. 

Clients report 'Error: the server could not process the request' under Troubleshooting --> connection status.
They do list the new server's name/IP.

Sounds like the new server is blocking some ports.

Do you have:

A. Windows Firewall turned on on the server?

B. SEP Firewall turned on as part of the client installation on the server?

I just verified that the firewall is off on the new server and the the clients can connect to both:

https://[old-server-ip & name]/secars/secars.dll?hello.secars (untrusted certificate warning received via browser)
https://[new-server-ip & name]/secars/secars.dll?hello.secars (untrusted certificate warning received via browser)

Perhaps I need to be a bit more specific about what is being attempted.
1. The new server was added to the mangement server list on the old server (name, IP, 443, 8014)
2. The new server has a different name / IP.
3. Both servers are using MS SQL DBs. Named sem5 and sem5new respectively
4. The Management Server Configuration Wizard was used on the new server with the disaster recover file from the old server (to get the certificate/etc)

Regards,
Thomas

Oh, I get it now.

So, you have not decommissioned your old server.

Basically, right now, you have 2 servers running simultaneously. 

Server 1 (old) and Server 2 (new).

You did not import the database into server 2, but rather only the certificate from server 1 in order to re-establish communications from your 500 clients to the new server.

You than created a management server list, which contains both the new server and the old server in the old servers management list.

Your clients have received the new management server list and can now "theoretically" communicate with both servers.

Your question than becomes, what's next for the clients to ditch the old server and move over to the new one - the catch, without using replication to avoid carrying over settings you don't want anymore.

* * * * * * *

1 - Create a new group (migration for arguments sake) on the old server.

2 - Create the same group (migration for arguments sake) on the new server.

3 - Place a few clients in that group.

4 - Change the management server list priority for the newly created group on the old server, and place the new server as the primary server for communication. 

What should happen next, is the clients, being told to move servers should ditch the old server and move to the new one... 

We're also hoping we can get the groups to re-create (without any of their settings) using the following
http://www.symantec.com/business/support/index?page=content&id=TECH160736

You can perform a disaster recovery without a database backup, but the following points apply in this case:

• All policies must be re-created, or imported from other backups i.e. exported policy files.
• Clients will be able to communicate with the SEPM but will re-appear in the console only after their next check-in.
• Clients will reappear in the default group as they check in, unless you enable automatic creation of client groups on the re-installed SEPM by adding "scm.agent.groupcreation=true" to the conf.properties file.
• If you originally had multiple SEPM domains beyond the default domain, you must re-create them using domain IDs from Backup.txt.

So we're just trying to get the communication with the new server issues resolved.

Regards,
Thomas

But that document refers to using the same name and IP for the new server. 

* * * * * * * * *

You are using the default port: 8014 for the SEPM server, and you can telnet to the port?  There are no other "web" services running on this machine?  Everyone is on the same subnet?

You could try to "trick" your clients...  Shutting down the "old server" and borrowing it's name and IP...  Using the name of the old server and it's IP address on the new server.  The certificate being the same, the clients should not be able to tell the difference and just connect.

The communication error is what is throwing the loop here.  It could be so many things, and because SEPM 12.1 is not using IIS anymore, it's harder to troubleshoot the web server issues (if any).

Follow up:

I moved forward with upgrading both the new and old server with SEPM Version 12.1.1101.401 to see if it fixed some of the issues we were encountering and found the souce of at least one of our problems on the old server.

The sem Database being stored on the MSSQL server had run into storage limits:

After the upgrade migration we got the following error as new SEP packages were being added.

THREAD 28 SEVERE: com.sygate.scm.server.metadata.MetadataException: Could not allocate space for object 'dbo.BINARY_FILE' in database 'sem5' because the 'FG_CONTENT' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

Increasing the size of the sem5_content (FG_CONTENT) limit fixed out ability to import those new SEP packages and also fixed issues with AV defitions not 'downloading/updating' properly on the SEPM server.

So now we are on the way to getting the old server fixed.  Depending on how that goes we may abandon creating the new server with its fresh database.