moving filer to new domain - few questions

[#1]

Hi all,

I've read a few posts regarding experiences people have had migrating people to new domains. 

Here's my situation/questions.

We're using 3rd party tools to handle sid copies etc between the 2 domains.  I have all of my filers, except 2 currently joined to a top level domain - domain.com.  The 2 remaining filers are joined to old.domain.com.  We're in the process of moving all of our accounts to new.domain.com (which both sets of accounts work fine on the filers that are members of domain.com). 

The changes are kind of 2 fold.  I also will be changing my cifs shares to add in newdomain\groups under the cifs shares.  This I believe is all I'd actually have to do to get the new domain accounts working on the existing shares.

The scarier part for me is changing the domain membership.  From what I've read you run a "cifs terminate" followed by "cifs setup" on the filer, and then re-register the filer in the (new) domain. You might have to manually delete the old machine account from AD before running "cifs setup".

What does this really involve?  I assume all cifs access is terminated during this?  Does the netapp prompt for admin credentials and it registers itself as a member server in the new domain?  What happens to existing cifs shares?  Are they retained during the membership change?  I ran a testdc and it can see all of the DC's for the new domain, so I don't think I'll have any problems.

Are there any other non-invasive ways of doing this?

Cheers,

-Derek

[#2]

The good news is you can always rejoin the old domain if any issues.  You will have an outage for cifs when you terminate.  The only time I have had to delete the domain account is when the domain credentials for the domain admin don't allow modification of an existing account.  The cifs shares and permissions should not disappear so you are safe there.  You could ask your NetApp SE for a temp key for flex_clone and multistore if you don't have those licenses.  Then create flexclones of all or some of the volumes, then a new vFiler which you can join to the new domain.  You will have to create cifs shares for the new vFiler, but it would be a good test since the data is identical from the FlexClone (same ntfs permissions on all files and directories).  A test of one or two shares (you would have to create since a new vfiler) is probably all you need to check to confirm it all works.

[#3]

good information.

A bit of a (more important) side question...

I want to make sure that the filers can talk to the DC's before making a disruption and I've found that I actually can't successfully run testdc against the parent domain and get it to find domain controllers (although the other filers that are already a member of the parent domain can without problems).  The only difference is all of those filers are in the same building as the domain controllers, and these ones are on a different network segment.  However these filers CAN query the new child domain which is on the same network as the parentdomain so I don't think it's a network type issue.

Does anyone have any ideas?  Or know if this would prevent a domain membership join from taking place (I would suspect it would fail). 

3020b> cifs testdc parentdomain.com

Current Mode of NBT is B Mode

Netbios scope ""

Registered names...

        NETAPP02A      < 0> Broadcast

        NETAPP02A      < 3> Broadcast

        NETAPP02A      <20> Broadcast

        OLDDOMAIN   < 0> Broadcast

Cannot find parentdomain.com domain's DC addresses.

Wed Dec 22 16:55:28 EST [3020b: auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- Found no PDC addresses through NetBIOS broadcast.

[#4]

If you ping "parentdomain.com" from the filer does it correctly resolve a domain controller?

If not, you may need to add "parentdomain.com" into your search domains in the nameserver list.

[#5]

it doesn't but in our environment we actually have parentdomain.com as a cname to www.parentdomain.com for our web presence... and since the web servers are in the DMZ the firewall is blocking those pings... which is just as well because the web servers certainly aren't our domain controllers. 

Which is strange... so I'm not really sure how all the other filers ended up getting configured on the parentdomain.com in AD.  They certainly can talk to the DC's in the domain and running cifs testdc against them ends successfully.

Is there a way that I can specify a DC to talk to during cifs setup and have that find the domain I want to bind the filer to?

[#6]

I'm really not sure in that case. Usually you'd have a separate DNS server internally to prevent these sort of issues, or you wouldn't use the root domain for any authentication purposes (or both). You may be able to trick something with a local hosts file. You can set preferred DC with "cifs prefdc" but I think that involves the domain already being configured.

[#7]

I'm starting to suspect that maybe the other filers were all joined to parentdomain.com before the cname for parentdomain.com was created for www.parentdomain.com

I'm going to take one of the other filers and join it to old.parentdomain.com and then try to re-join it to parentdomain.com to see if it is able to connect.  If it can't then that will make sense (suspecting that the only reason testdc passes on them now is due to them already joined to the domain)..

If it can... then back to the drawing board.