Thanks, Sandip - that's very helpful!

By "pre-stage", I mean pre-create the computer account in AD.  I get delegated authority to join CIFS servers to AD - our Windows team prefers to put the computers into a different OU, per an internal policy.  This is to prevent me from goofing up where the object goes, and they can be sure it matches their naming convention.

Here's the wrinkle - I'd like to use the same IP address when the CIFS servers move between domains.  We manage DNS in the new domain as well, but we get the IP allocations from another party.  They're not willing to relinquish enough IP addresses for me to give the CIFS servers new IP addresses, so I'll need to reuse them.  Yes - I know that users will experience an outage, if I have to temporarily remove the IP, but this decision is being driven by politics (wait, aren't all IT decisions basically political?!?).

So, I'll have to add a step for "delete CIFS server" before I can even create the new CIFS server with the same IP?

Thanks very much!

Thanks, Sandip - I just looked up Rainer's post on the interface stealing trick, and this looks pretty good.

I'm scheduled to make all of these changes April 25-30th, so I'll test this out over the next few weeks.  If I have any other useful tips, tricks or "Do NOT do this!" discoveries, I'll put them here.

Thanks again have a great weekend!

Karl

My absolute pleasure - you also make it a Great Weekend - cheers,

Sandip

Karl,

I am pretty confident, you NEED NOTto delete the old CIFS server - once you unjoin the old CIFS server from the domain, it still uses the IP Address - but what you can do is - you then create the new CIFS server and use the same IP Address which was used by the old CIFS server.

This will steal the Interface (IP Address) from the Old CIFS server to the new CIFS server. I remember, Rainer had mentioned Interface Stealing few times earlier in this forum - for some other purpose.

So, now - you have two CIFS servers - the new one is having the IP and joined to the Purple AD - the old one is unjoined and does not have any IP Address.

Hope this helps - to be in safer side, you may test this out before implementing,

All the best,
Sandip

I'd be curious to hear your results.

Sure thing - the migrations won't happen until the week of April 26th, so you probably won't hear much until then.  Thanks!

Karl

So far, so good.  On Friday, I tried to moved my first server with this procedure.  However, the admins did not give me rights to unjoin the objects from the old AD (ORANGE) and the new AD (PURPLE).  I shortened my steps to the following:

• Pre-stage computer object DEPT-PROD1 in PURPLE AD
• Unjoin  CIFS server ORANGE\PROD1 from ORANGE AD (to free up the IP interface)  with server_cifs -unjoin command
• Delete  old CIFS server ORANGE\PROD1 with server_cifs -delete  command (this freed up the IP interface and left the old computer object in ORANGE AD)
• Create  new CIFS server, DEPT-PROD1 on Celerra with server_cifs  -create command
• Join new CIFS server, PURPLE\DEPT-PROD1  to PURPLE AD with server_cifs -Join command
• Re-create  CIFS shares using server_export command
• Notify Windows Admins to remove the old computer objects from ORANGE AD

This worked swimmingly, save for lengthy AD DDNS and DC replication delays (almost 30 minutes).  There was no need to recreate the share permissions - they were embedded in the filesystem (or perhaps hidden in .etc in the VDM, someplace).  Users were disconnected from the NAS, when the old CIFS server was deleted, but most of them seemed to reconnect automatically when DNS finally lined up.  All told, the process to move each CIFS server takes less than three minutes from the CLI - our own DNS delays made it take much longer.

I made a similar change today, moving two more CIFS servers.  I saw the same DNS delays (on the AD side, again, not with the Celerra).  I also discovered that the Windows guys appeared to pre-stage ACLs on the computer object (or perhaps they had a GPO that did it for them).  When I joined one CIFS server, it had automatically picked up an administrative group from the new AD.  If you've got access to this in your AD, you might want to take advantage of this.

Thanks!

Karl

Thanks for the update Karl - nice to see that things worked so well for you - well done.

Cheers,
Sandip

Hi,

It looks like it worked for you pretty good, I have a customer with over 100+ cifs servers planning to migrate all of them to a different domain as they are going to retire the current one. I did the same process on a test case and was fine and the customer had all ACL's and SID's intact. But I am planning to use Migrate/Replace instead of this process. The following is my approach. Can anybody comment on pros/cons of this approach Please.

Source Domain : AD.qintra.com

Target Domain. CTL.Intranet

Cifs Server : veldnp3h

Run migrate command with localgroup option

server_cifs veldnp3h_vdm -Migrate veldnp3h -localgroup ad.qintra.com:nb=veldnp3h ctl.intranet:nb=veldnp3h <<< Succeeded

Run Replace Command move SID's

Using a Replace to update all SID history of old domain to new domain

server_cifs veldnp3h_vdm -Replace veldnp3h -localgroup :nb=veldnp3h <<< Succeeded

Unexport the shares

Unjoined from AD domain <<<< To get the CIFS server to move to CTL the only way is to delete from AD and recreate (Add & Join) to CTL Domain) : NEED  SOME VERIFICATION

Now Delete veldnp3h from AD

server_cifs veldnp3h_vdm -delete compname=veldnp3h

Now Add veldnp3h to CTL domain

server_cifs veldnp3h_vdm -add compname=veldnp3h,domain=ctl.intranet,netbios=veldnp3h,interface=veldnp3h

Join the Domain

server_cifs veldnp3h_vdm -Join compname=veldnp3h,domain=ctl.intranet,admin=sa-admin@ctl.intranet,ou="ou=EMC*Celerra:ou=Domain*Servers"

Export the shares