Windows patching for Waters servers

krhynard

Hello all,
we have this general issue, how do most of you handle this?

Currently, the only way to determine if Windows OS patches have been tested with Waters informatics products is to review the release notes pertaining to a specific version,  feature release or service pack.

As you may know, Microsoft releases Windows OS security patches at least once a month, sometimes more frequently.

The effect of this combination is that the list of patches tested by Waters is always far behind what has currently been released.

 As a global company, security is a priority and our policies do not allow us to wait six months for an approved patch. However, our support plan with Waters will not guarantee support if we use patches that have not been tested by Waters. I expect we are not alone in this requirement, any company that shares information across the internet is at risk.

 As an alternative, we have been forced to assess patches ourselves by extensive application testing internally. This provides a significant burden, but at current, there is no alternative.

That being said, I would like your feedback on how you handle this. 

HeatherLongden

Hi.. I'm going to check out the validity of this sentence for you:
"our support plan with Waters will not guarantee support if we use patches that have not been tested by Waters"

JohnWalsh

Hi 

To follow up on Heather's comment, 

It is is not Waters policy to deny support to Empower customers based on their configuration including Microsoft and other OS hotfixes. 

Thanks

John Walsh 
Principal Support and Consulting Support Engineer
Waters 

MJS

My Company Details: Large, global w/ multiple labs, but not all are on the same instance of Empower depending on their scope.  My instance of Empower is not intended for commercial batch release but we do some GXP level work for product submissions, otherwise mostly R&D.

With regard to basic OS patches, we have taken a stance that such updates are low risk and therefore do not require testing prior to deployment.  This clearly may not work for everyone, but for what we are scoped for, we are okay with it on a risk-based approach.  For more significant changes like a full service pack release, I would be expected to do some testing.  I am lucky enough to currently have a test environment where I can execute testing as desired and, depending on the nature of the change, IT can create virtual environments for me to test in.  These are very helpful when it is a secondary app, IE for example, where Empower has stated compatibility with version 1, but then IT wants us on version 2 which is not likely to affect Empower acquisition/processing/etc., but we may want to at least do a small check to be sure it won't break our Citrix connectivity before rolling it out to the users/LACEs/servers.

Could you expand on the nature of your testing?  What do you mean by extensive application testing?  More than a simple SoftwareQT test?  Patch/hotfix testing on an individual basis or as a monthly group?  Documentation around what can be a very long list of patches?

One last note, I don't think anyone from Waters has ever questioned my patch level when attempting to troubleshoot anything.  The closest I would say they ever came to this is when I was having a printer driver issue on a Citrix server (initially observed as Empower hanging when loading the background processing screen or loading the preview/publisher) as we eventually thought that maybe IT had pushed a new printer driver that was somehow not compatible with Empower.  Turned out to be a corrupted one that needed to be repaired/re-installed is all.