re; emc156835 Yes, the primus could be better--slightlty revised it. If you are starting out with a CIFS Server (or VDM cifs server) with one name, but then need to change its name yet retain all its permission structures, then that's the purpose for the primus. Step 4 creates the Netbios name and entries needed for the Localgroups file on the Server. Step 5 deletes thte Netbios name so that in step6 you can create the COmpname equiv. of the netbios name, as well as Join it to the domain.
so in step 5 i delete the netbios name ..at this point what's holding information about my cifs server? Netbios name has been deleted so has compname. In step 6 i add compname again ..how does it know to re-use the information about the old CIFS server ..instead of creating a brand new compname with brand new local groups ?
all the magic is done with the Server's localgroups file--once entries are created in this file, they never go away. that's why the procedure looks convoluted, but works.
this is interesting ..i actually see a problem here. I just looked in the file and see that it contains my system name before it got renamed. So i just looked in AD ..and sure enough my CIFS server joined to AD with its old name. When i run server_cifs VDM ..it shows correct name. What do i do now ?
well, there really isn't anything preventing a customer from looking at the file if they know where to look--I assume you are talking about the localgroups? From the control station, just cd to /nasmcd/quota/slot_x/.etc and ls -la and look for .db.localgroups. you can cat or view the file to see the contents, etc.
Are you sure you followed all the steps in the procedure?
I think I mentioned this before, but once an entry is made to the localgroups file, it doesn't get deleted, so it should have the old name listed.
As for what AD shows, that sounds like a matter of whether the original name was successfully Unjoined and removed from AD and whether the new compname was successfully Joined and added to AD.
yes ..followed instructions word by word. I am going to unjoin CIFS server ..delete it's computer account ..force AD replication ..and then rejoin it. Hopefully that will take care of it.
we got it fixed but it was really strange situation. In AD it showed computer name "servername-new" ..while on Celerra it showed just "servername" (server_cifs VDM command). So when i tried to unjoin "servername" from AD ..it failed saying that computer account "servername" does not exist in AD, i went ahead and issued unjoin command but instead of specifying my CIFS server name i specified the computer name that i actually saw in AD (servername-new). The command worked and servername-new account got deleted from AD. At this point i ran server_cifs VDM command and it still showed that my "servername" cifs server was joined to AD. I thought this was going to be a problem if i try to join it again ...since on the Celerra side it showed it was already joined, but i decided to try again anyway. I went ahead and forced AD replication ..waited for 20min and issued my join command anyway, the command succeeded and i saw correct computer account show up in AD. So for me lesson learned is whenever i migrate from physical server to CIFS and it involves swapping name, i have to either force AD replication or just wait for regular replication cycle to take effect before renaming my CIFS server and join it to AD.
Not to hijack the thread, but is this also valid for changing the domain of a CIFS serevr? I started a discussion in this thread - https://community.emc.com/message/462759#462759 , along with what I hope are the right steps to follow.
I have CIFS servers in a domain called PURPLE, that will be retired this month. There's a new AD domain, ORANGE that has a two-way trust relationship with PURPLE. I've already ACL'd filesystems, such that accounts in the ORANGE have Full Control in PURPLE and so on.
Would I be able to use these steps instead of my process?
One time i had to rename a CIFS server, i unjoined it from AD and while i was renaming it , i misspelled the domain name. I went through the same process and rename it again. So maybe you can rename it to temp name and then rename it back with new domain name ? It can be easy to test if you have Celerra simulator and another VM with Windows 2003 server running DC/DNS for a test domain name ..Microsoft.local or something like that.
Sigh. No. Policy dictates that the "Virtualization Team" gets to manage the VM environment. I have no rights to install the application on my desktop, so I have to request the install from the App Team. They see "VM" in the title and I get no where. Fast.
I've asked my manager about it - we have a few unclear "regulations" that could be misinterpreted, so our documented policy is such that no one can run an "unauthorized" VM anywhere, anytime. And we have the administrative ACLs set on the desktop machines to enforce it.
mattat
13 Posts
1
September 17th, 2007 09:00
Yes, the primus could be better--slightlty revised it. If you are starting out with a CIFS Server (or VDM cifs server) with one name, but then need to change its name yet retain all its permission structures, then that's the purpose for the primus. Step 4 creates the Netbios name and entries needed for the Localgroups file on the Server. Step 5 deletes thte Netbios name so that in step6 you can create the COmpname equiv. of the netbios name, as well as Join it to the domain.
dynamox
9 Legend
•
20.4K Posts
0
September 18th, 2007 05:00
thanks
mattat
13 Posts
1
September 18th, 2007 07:00
dynamox
9 Legend
•
20.4K Posts
0
September 18th, 2007 09:00
dynamox
9 Legend
•
20.4K Posts
0
September 18th, 2007 10:00
Thanks
mattat
13 Posts
0
September 18th, 2007 10:00
mattat
13 Posts
0
September 19th, 2007 11:00
I think I mentioned this before, but once an entry is made to the localgroups file, it doesn't get deleted, so it should have the old name listed.
As for what AD shows, that sounds like a matter of whether the original name was successfully Unjoined and removed from AD and whether the new compname was successfully Joined and added to AD.
dynamox
9 Legend
•
20.4K Posts
0
September 19th, 2007 13:00
mattat
13 Posts
0
September 20th, 2007 05:00
dynamox
9 Legend
•
20.4K Posts
0
September 23rd, 2007 07:00
umichklewis_ac7b91
300 Posts
0
April 22nd, 2010 11:00
Hi guys -
Not to hijack the thread, but is this also valid for changing the domain of a CIFS serevr? I started a discussion in this thread - https://community.emc.com/message/462759#462759 , along with what I hope are the right steps to follow.
I have CIFS servers in a domain called PURPLE, that will be retired this month. There's a new AD domain, ORANGE that has a two-way trust relationship with PURPLE. I've already ACL'd filesystems, such that accounts in the ORANGE have Full Control in PURPLE and so on.
Would I be able to use these steps instead of my process?
Thanks!
Karl
dynamox
9 Legend
•
20.4K Posts
0
April 22nd, 2010 14:00
Can you install VMware player ?
dynamox
9 Legend
•
20.4K Posts
0
April 22nd, 2010 14:00
Hi Karl,
One time i had to rename a CIFS server, i unjoined it from AD and while i was renaming it , i misspelled the domain name. I went through the same process and rename it again. So maybe you can rename it to temp name and then rename it back with new domain name ? It can be easy to test if you have Celerra simulator and another VM with Windows 2003 server running DC/DNS for a test domain name ..Microsoft.local or something like that.
umichklewis_ac7b91
300 Posts
0
April 22nd, 2010 14:00
Thanks!
Yeah, if I could ever get permission to install VMware on a workstation I have access to. I don't suppose I can run Celerra Simulator on Hyper-V...?
umichklewis_ac7b91
300 Posts
0
April 22nd, 2010 14:00
Sigh. No. Policy dictates that the "Virtualization Team" gets to manage the VM environment. I have no rights to install the application on my desktop, so I have to request the install from the App Team. They see "VM" in the title and I get no where. Fast.
I've asked my manager about it - we have a few unclear "regulations" that could be misinterpreted, so our documented policy is such that no one can run an "unauthorized" VM anywhere, anytime. And we have the administrative ACLs set on the desktop machines to enforce it.
Thanks!
Karl