2013-04-02 03:59 PM
IHAC that is moving a group of Windows servers and filers to a new AD domain. The servers are running SnapManager for SQL which of course needs SnapDrive. They need to know the best procedure they should follow to accomplish this with minimal down time. Currently there is a "trust" between the two domains, but that will eventually be broken. Note that while the filer is in the AD domain, it is not serving up CIFS shares, just LUNs. What would be the best way to accomplish the migration? I'm thinking:
1) Change the domain of the host. (the existing service account should work because of the trust between the domains)
2) Change the domain of the filer. (the existing service account should work because of the trust between the domains)
3) Update the service account that SnapDrive uses to an account in the new domain (how do you do this by the way?)
4) Break trust of the two AD domains.
2013-04-02 04:36 PM
Technically, you can have snapdrive and NOT participate in a domain at all. Try changing the snapdrive transport protocol to HTTP or HTTPS and use an account local to the controller (that happens to be a member of the Administrators group). This will send ZAPI calls back to ONTAP bypassing the AD domain. Then, while in domain transition, you can use a local SQL server login ( mixed authentication) for SMSQL to do its functions. This account can also exist entirely on the SQL Server instance and not need be a domain account.
2013-04-02 04:42 PM
Thanks, but the customer tells me that for security reasons they don't allow local accounts to be created on the filers. But this does bring up another question. They did happen to mention to me they want to move to HTTPS transport. Just to confirm, can you use HTTPS with domain based accounts?
2013-04-02 04:57 PM
No, they can't use a domain account for HTTP/HTTPS transport protocol authentication in SnapDrive.
So, to answer the original question. You change the service account the same way you would change a regular windows service credentials. You use the 'login' tab in the service properties from the services mmc
At this point, whatever domains the host is a member of, those accounts will be available for use for the service.
I will however call shennanigans on the customer's "security" policy. Whether they like it or not, they have local logins on the controller ... At least one, by default in the 'root' account. And the local 'Administrator' account if they have ever run cifs setup.
Just as an fyi, you can use either of those afforementioned accounts as the zapi call account for SnapDrive
It's also worth pointing out that if they ever plan to move to Clustered ONTAP then they will no longer be able to use RPC as the transport protocol for SnapDrive (the protocol that uses the service account as the credentials for ZAPI as it seems they are configured now) going forward, they will have to use HTTP or HTTPS.
2013-04-02 05:09 PM
Hmm, according to the installation manual regarding using HTTPS:
Note: If you set up SnapDrive to use HTTP or HTTPS to communicate with storage
systems, using the domain Administrator account for authentication results in significantly
reduced performance. To avoid this issue, use a storage system account for authentication
instead of the domain account.
So, from that I would think you could use a domain account, it just isn't recommended for performance reasons. Thanks for pointing that out to me.
Last question, what do you think of my order of changing things listed in the original post?