SEC migration to Windows Server 2016 [was: Windows 2016 upgrade]

Hello Akhil,

I've taken the liberty to a) move your post to the Console forum because as far as I understand your question it is about the SEC migration, and b) to edit the subject accordingly (if I'm wrong please say so).

VMWare shouldn't be a concern, from SEC's POV it doesn't matter whether it's a physical or virtual server. The procedure is described in the Enterprise Console server to server migration guide. Please note the Assumptions in chapter 3. 

Christian

QC,

I am planning for a similar if not the same migration scenario.  I have a question regarding to the Sophos Update Manager password.  Section 6.1 of the SEC migration guide refers to "Check Update Manager password."  This may be my first hurdle in the migration because of an unknow SUM password.  However, our SUMs provide updates to endpoints using Web CID or IIS.  There is no username and password configured in the updating policies.  The only credentials we have set in the updating policies is for connecting to Sophos as a Secondary Server.  Also, the migration guide doesn't mention setting up IIS as update source.  Are there some notes on this particular configuration? 

Thank you,

Dusty

Hello Dusty,

off the top of my head:

Installation requires two accounts, the SUM account is "just" used to provide access to the Default update share in the Default updating policy. So on the new server you can choose whatever account with whatever password. If you restore the database on the new server the old values are in the policies - if you use this account in the policies but it doesn't match the new one updates fail and you'll have to amend the policies. If you do not use this account - well, it doesn't matter what password you choose.

IIS is one possibility to publish the CIDs via HTTP. The web server could be local or remote. It has to be able to read from the share(s) (here the SUM account comes into play but IIS does not get the credentials from SEC) and it has to provide the paths expected in the policies. SEC/SUM does otherwise not care about the web server's setup, it's independent and therefore not mentioned in the migration scenario. Going from W2k8R2 to W2016, onboard IIS I simply copied the configuration.

Christian

Hello Dusty,

off the top of my head:

Installation requires two accounts, the SUM account is "just" used to provide access to the Default update share in the Default updating policy. So on the new server you can choose whatever account with whatever password. If you restore the database on the new server the old values are in the policies - if you use this account in the policies but it doesn't match the new one updates fail and you'll have to amend the policies. If you do not use this account - well, it doesn't matter what password you choose.

IIS is one possibility to publish the CIDs via HTTP. The web server could be local or remote. It has to be able to read from the share(s) (here the SUM account comes into play but IIS does not get the credentials from SEC) and it has to provide the paths expected in the policies. SEC/SUM does otherwise not care about the web server's setup, it's independent and therefore not mentioned in the migration scenario. Going from W2k8R2 to W2016, onboard IIS I simply copied the configuration.

Christian

Thank you for replying.  It looks like I will have to "reset the SUM password."  The migration notes mention creating a new SUM account.  Is there any advantage to creating a new local account vs. resetting the password of the domain service account used for SUM?

Thx again,

Dusty

Hello Dusty,

if your management server isn't also a DC (which is strongly advised against) you can use a local or Domain account, both work. IMO it's more a question of an organization's security policies, e.g. who can re-enable the account. Depends on whether only Domain-Admins are server admins or servers have also local admins. If you don't use the account in the policies it doesn't matter at all, I'd say.

Is there any advantage
not really, you'd have to amend the affected policies in both cases. Of course if you create a new account you'd have to modify both user and password.

Christian
 

Negative..  our management server isn't a DC.  That is what I was thinking in regards to needing the SUM account if it isn't used in the policies. 

Hello Dusty,

the installer simply wants this (or rather an) account for the documented purpose (basically putting it into the Default updating policy and verifying access to the Default share) at install time. AFAIK neither SEC nor SUM check or use these credentials anytime later.

Christian

Got it.  Moving forward with the migration this week.  Will the endpoints see any messages in the system tray when they are unable to communicate with the SEC?  Our endpoints do not update directly from the SEC.  They update from a couple of SUMs.    I wouldn't think the endpoints will see any messages.

Thanks,

Dusty

Hi dluneau 

If the endpoints do not communicate with SEC, it might give you the error for endpoints showing disconnected on the SEC dashboard. Please check this article for more information. If they are updating from a couple of SUMs, endpoints should be updating fine.