Hi,
We will be moving some VMs hosting our DMS to another domain and have some questions around this.
Current State
- DataMiner application is configured with LDAP for nbnco domain & all the service accounts are nbnco\<service_account>
- Windows OS on Dataminer VM is integrated with nbndc domain
- MSSQL Database on each DataMiner VM is using Windows Authentication & have nbndc\<service_account> configured for SQL Server Agent & SQL server Database Engine
AD & LDAP Migration
- DataMiner application will be configured with LDAP for nbnan domain
- DataMiner VM will be moved to nbnrs domain
Queries
Considering the above we are trying to develop smooth migration strategy with minimum downtime & in the process have below queries
- What should be the process to change service account in MSSQL, will it disrupt the connectivity (restart required?) with DataMiner
- Do we need to update MSSQL service account in each DataMiner server (active & standby within a team)?
- Is there any corresponding change in DataMiner application after changing service account in MSSQL Database?
- Can we migrate MSSQL & DataMiner application independent of each other?
- Can we make above changes in each team independently?
- Does LDAP config update requires DataMiner restart?
- How will it impact the whole cluster if one team is updated with new LDAP & MSSQL service account but remaining teams are still on the old LDAP & MSSQL service account? (Like accessing all elements from any DataMiner, Alarms etc.)
Thanks!
-Related to the MSSQL user, we just use the user from the settings you filled in in the DB settings, you can change this in the db.xml file or in cube (system center > database), if you change this user my recommendation would be to check the connection from the DMA server itself with a simple command or tool to be sure you can connect towards that DB to that user
For MSSQL we use that specific user for every query, so as soon as the authentication is successful the queries should work fine.
If you have period in time we cannot connect we will start to buffer the content that needs to be pushed towards the database in cache files, it's however possible if this buffering goes on for too long that it's "too much" to still push to the DB and these cache files will need to be cleaned up to recover from this
-Changing the LDAP settings on the DMA is a bit more tricky, my recommendation would be here to first of all use the latest DMA version since we've recently did quite some improvements towards stability and performance of making LDAP changes
The cleanest procedure would probably be to remove first all the domain users and groups, make sure you made some local users that you can keep working on the system while doing so
Once everything is removed you can change the LDAP settings as mentioned in our help:
Finally once the new LDAP is configured you can add again the new users/groups and configure those again