Safeguard Enterprise server over Internet not via VPN

Can you route to the website in a browser? 

If you can - does the page display properly?

On the SGN server - do an invoke test and see what it returns.

We renewed a certificate on our secondary server, would that effect it?

Then you could push out all the certs from the DC? How many PC's are there?

About 200 plus, it's fine when connected via our vpn for domain users, but it's more of an issue with the WORKGROUPS now not able to sync

Ah ha, you have domain bound AND Workgroup? Obviously you'll not be able to use the DC to push out to those and as it's an internal cert your easy options are limited. I would create a new configuration file and install that. Unless the WG PC's are managed by some sort of MDM?

No unfortunately, our Domains will be fine as the certs gets pushed out but it was more for our workgroups, but because we found that when our domains weren't connected via the vpn it was erroring when syncing but that's because our secondary server which is setup for that the cert expired and was renewed.

One of the reasons my secondary is in the DMZ and has a public cert! I'm afraid your options are...config file....or install the certs manually. How many WG PC's are there - it that the 200 plus figure or is that the whole estate?

Probably the same if not more, however we will hopefully be moving away from workgroups in the future, so with this in mind it's not that urgent, but can I ask what issues we will stumble across if we leave it? I presume from a support side we can still recover Bitlocker codes via the helpdesk etc?

If there's a primary server that still works - no real issues at all. Your secondary is there purely as a failover to the primary should that become unavailable. Yes - as long as the primary remains up and there's a server to communicate with every X minutes (what's ever set as your policy). I would personally resolve it - but appreciate it's hassle. 

Hi Michael

Thanks for all the advice you've given Dan P already, much appreciated.

We had this secondary server set up to allow all our Citrix users' computers to sync with SGS. These computers are remote (no direct connection to our network, no VPN, etc) and they are workgroup only.

What that in mind I just have a couple of follow-up questions I wonder if you could clarify please?

1) Our secondary server is in the DMZ (or port-forwarded, strictly speaking). Given what you said above, about keeping your server in a DMZ and using a public cert, if we purchased a public cert for this server, to replace the one from our CA, would that allow these remote workgroup clients to start synchronising again?

2) If we don't resolve this, what's the implication for these clients? Is it basically just that they won't be able to sync any new policies or changes to existing ones? We don't really ever change the policies that we created at the beginning, so we could probably live with that until we eventually move away from Citrix.

many thanks

Dan W

Hi other Dan!

1 - In theory this should work. Assuming the public CA AND the supporting intermediaries are publicly accessible so the chain doesnt break down. Is this secondary server ONLY for the workgroup devices, or do the domain devices use this as their secondary too? Do the workgroup devices ever use the primary?

2 - If the clients fail to report back to the server then they'll fail to report back any BL changes. This could mean the server does not have a copy of the current recovery key if the key rotates after use. It also means no policies as you pointed out. Something you could possibly live with IF you're running the very latest client and backend. If you're not and you need to change the backend or client - You will have to assume the server doesn't change the behaviour of the client. This has happened before where an update for me personally caused OneDrive to really mess up. It turned out the File Encryption policy had to be modified - even though I wasnt using it. 

I'm not sure of your own timeline but you're probably aware that SSG has been declared EOL now and won't be any new versions as such. How much effort you want to put into this, combined with a planned move away from Citrix I don't know. As I said, I would resolve this mainly for rhe issue of outdated RK's on the server. It's only going to take one user to kick off if their drive needs a RK and helpdesk can't produce one (or at least a current one that works!)

Hi Michael

Thanks for the reply.

In answer to your question, from memory all endpoints are configured to try the primary first, and then the secondary if they can't reach the primary. So although the workgroup devices will attempt to contact the primary first, they'll never find it and will always fail over to the secondary. This was how it was set up by our Sophos partner a couple of years ago.

Dan

Hi Michael

Thanks for the reply.

In answer to your question, from memory all endpoints are configured to try the primary first, and then the secondary if they can't reach the primary. So although the workgroup devices will attempt to contact the primary first, they'll never find it and will always fail over to the secondary. This was how it was set up by our Sophos partner a couple of years ago.

Dan