Symantec End Point (SEP) moving clients to a new SEP Management Console

We recently installed a new SEPM as the other one malfunctioned and were faced with the task of either reinstalling the SEP client on every device or else find a way of simply modifying the client to point to the new manager. Obviously the path of least effort was preferred.  

After doing some searching on Google the following steps were found on how to accomplish this:

This worked but we ran into one or two issues I would like to highlight:

1. We had monitoring enabled on all servers so stopping the smc.exe service resulted in the ‘self-healing’ capability of the software simply restarting it again before we could paste the xml file onto the server. We resolved this by: 
1. Setting the service to ‘Disabled’,
2. Stopping the service,
3. Pasting the file,
4. Setting the service back to ‘Automatic’ and starting the service.
2. The pasted xml file you require should be taken from a device of equal version and architecture e.g. Server 2008 R2 x64 to another Server 2008 R2 x64.
3. Once the client has reported into the new SEPM it will show in its previous default location in the clients module on the SEPM. To enact the new policy simply move the client to the correct location and then update the policy on the device.

C

Symantec End Point Protection and Microsoft Hyper-V

Recently we deployed a new Hyper-V host and secured it from Malware by installing Symantec End Point (SEP). Although there are those out there that believe installing anti-malware on a server with the role of host only is not recommended, we decided to do this due to the fact that source software was going to be copied to the server from what we deemed was an untrusted source.

After a few days the virtual machines running on the server could only see each other and not other servers or virtual servers on the network. We discovered that the SEP client was blocking access to the network and once we uninstalled the client network connectivity was re-established and has been stable ever since.

Lesson:

1. Deploy Hyper-V with properly configured anti-malware and once VM deployment is complete, remove the file shares, the executable data and the anti-malware client.

C

Public Certificates from ‘Newer’ Trusted Root Certificate Authorities

Recently we went live with a secure site which was secured using a public certificate issues by a Root Certificate Authority.

During User Acceptance Testing we found that some clients were showing a browser error stating that the certificate had been issued by an untrusted source.

On investigating the issue we found that the Root Certificate Authority which had issued the certificate was not published as a Trusted Root Certificate Authority in the Certificates MMC Snap-In on the clients showing the error. A little further investigation uncovered that the authority in question had only been added to the list in the last twelve months.

The issue was resolved by running Windows updates on the client machines… which had not been done for some time! Two of the Windows Updates amended the Trusted Root Certificate Authority list and once the clients were restarted the certificate warning went away.

Two lessons:

1. Always run your Windows Updates.

2. Choose an authority that has been on the list for a longer period of time.

C

IIS 7.5 Redirect HTTP to HTTPS

Recently we deployed a secure website that needed to automatically redirect HTTP traffic to HTTPS. This is quite easy to do if the site is published using Microsoft ISA / TMG but as this was a hosted product on a third party Firewall we needed to do the redirect using IIS only.

The site was running on IIS 7.5 and we performed the following steps:

1. Open the IIS Management Console, Click on the site in question and then double-click on SSL settings.

 

2. Tick the ‘Require SSL’ Box

3. Go back to the IIS Management Console and double-click on the IIS Error Pages icon. Not the .Net Error pages… as shown in the screen clipping below.

4. Double-Click the 403 error and in the dialog box that opens select respond with a 302 redirect and then enter the https://urlname that it needs to redirect to.

5. Click OK and your HTTP site will now automatically redirect to HTTPS

C

TMG Site-to-Site VPN

I recently deployed a TMG site-to-site VPN from our Head Office to a Hosted Environment where the majority of our production servers / services are located.

I followed the instructions on TechNet (http://technet.microsoft.com/en-us/library/bb838949.aspx) to the letter but ran into some peculiar difficulties which are not documented anywhere I searched.

Below are a list of a few tips and tricks to get the VPN up and stable:

1. You need to create a user for dial-in access as the configuration utilises the Microsoft Routing and Remote Access Service. I recommend that you create a user on each side of the tunnel with the identical name as this eliminates the confusion on which user to configure in which setup. If you running AD create local accounts on each TMG server.

2. Ensure any Firewalls configured between the two TMG servers are either disabled or allow all inbound traffic. This is particularly important if you are configuring via DSL routers.

3. Some ISP’s do not enable Generic Routing Encapsulation (GRE) on their network. Your VPN will not work if the ISP does not support this.

4. It is better to configure your VPN wizard with the IP address of the other side rather than using a DNS lookup as the timing difference causes the connection to fail in highly utilised network environments.

5. Once you have configured the VPN wizard on both TMG servers you need to access the RRAS MMC interface and start the demand-dial interface which TMG should have created. If it has not  created the interface you can manually create one or else stop and restart the service. This might take a few tries to get right and this is the most ‘fun’ you will have during the configuration.

6. When you are first setting up the VPN you may be forced to restart the RRAS service often. It is a good idea to restart the servers once all is configured to ensure the VPN comes up on its own once the servers reconnect.

That about covers the ‘undocumented’ issues I ran into while configuring the VPN and I hope this post helps someone out there.

C.