>Then once the operation of these clients was stabilized, upgrade 
>our 4 servers one at a time. As each server is upgraded, 
>the already-updated client would cause certificates to be 
>exchanged and that Admin ID to be switched to STRICT, which 
>would be OK since all of the client nodes where that Admin 
>ID might log in from would already be at V7.1.8/8.1.2+. 

Do your servers talk to each other?  

Our servers are all setup with server-to-server communications for a 
library sharing environment and moving node data between servers.  
Are there issues upgrading servers one at a time when the 
servers talk to each other?


Rick




-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Deschner, Roger Douglas
Sent: Thursday, March 1, 2018 8:00 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [EXTERNAL] v7.1.8/8.1.2 SSL Upgrade: Rethinking servers first or 
clients first

I've been using our test setup for further testing, and I'm thinking of 
reversing my strategy. I may want to upgrade clients first, and then servers.

The basic issue is still how to overcome the roadblock of having an 
Administrator ID automatically switched from TRANSITIONAL to STRICT upon first 
login from a 7.1.8/8.1.2+ dsmadmc client. IBM seems to think we can upgrade all 
servers and all clients to 7.1.8/8.1.2+ simultaneously. That is not practical.

In the worst case, this automatic switching could cause the System 
Administrator's worst nightmare - to lose control over a running system. 

I am still considering the (very ugly) bypass of an administrative schedule 
that sets it back to TRANSITIONAL for all Admin IDs every 5 minutes. There will 
still be some failures.

But I am also considering reversing the strategy I had considered earlier, to a 
different strategy of upgrading all of the clients involved (about 7 of them, I 
think, but I'm not sure) to 7.1.8 or 8.1.4 first, while the servers are all 
still running older versions. So far, everything would be working.

Then doublecheck that there are not any left behind by scanning activity logs, 
the summary file, etc. 

Then once the operation of these clients was stabilized, upgrade our 4 servers 
one at a time. As each server is upgraded, the already-updated client would 
cause certificates to be exchanged and that Admin ID to be switched to STRICT, 
which would be OK since all of the client nodes where that Admin ID might log 
in from would already be at V7.1.8/8.1.2+. (At least we hope. This may expose 
those we forgot.)

Unless I'm overlooking something big here, I think this would allow us to 
upgrade each client and each server independently, and iron out any issues one 
at a time. Any comments on this client-first strategy?

Roger Deschner
University of Illinois at Chicago
"I have not lost my mind; it is backed up on tape somewhere."
------------------------------------------------------------------------------

The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.