Our current environment is all virtualized on ESX5.5. We have approximately 10 servers running SLES11SP3 with OES 8.8 SP8 . Some of the physical hardware is too old to support VMWare/ESX 6.5 so I will be getting some supported hardware. As of now, we have a file server and a 'services' server that runs DNS/DHCP, and LDAP in each location. My plan is to stand up a brand new server on the new VMWare 6.5 host with OES2018SP1 and upgrade the exisitng tree in doing so. I would make a new server the master replica. I would then build file servers and migrate user files. Are there any 'gotchas' with this scenario? It's not going to be instant so is there a problem with a mixed environment having two different versions of eDirectory?
TL;DR We have all old stuff, no in place upgrades of SUSE or eDir. Any problems upgrading the tree with new OES2018SP1 servers and old servers running 8.8SP8?
I haven't had too many problems doing in-place cold upgrades of virtualised servers from OES11.x on SLES11.x to OES2018SP1 on SLES12SP3. In this you boot off the SLES/OES iso and perform the upgrade. This also works pretty well. You could then offline them and migrate the servers to your new VMware hosts.
Building fresh servers will also work fine, and there is generally no issue will mixing edir 8.8 and 9.x servers in a tree. That will be a bigger task since as you say you will need to migrate the NSS volumes. And of course if this is a new server, the resources will have a different UNC. You can use traditional miggui type tools, or just take the old server offline and copy the vmdk with the NSS volumes to the new server in the same tree and add it. The new server will see the NSS and using nssmu you can update edirectory with the pool and volume objects. The only down side of this is that you cannot use the new partition type immediately for super large volumes. However, here the newer NSS move functionality makes resizing onto a new partition an easy background task.
You don't say what OES version you have: 8.8 is an eDir version number with many subversions such as 8.8.8 patch 11 and a build number like 20812.20 - "rcndsd status" helps here. The current SLES and OES versions are simply reported with "cat /etc/*release". For an in-place upgrade you will need OES11 SP2 as a minimum to do this in one hop, else go to OES2015 SP1 first.
Support
Documentation
Learning Services
Partner Programs