How to copy user database from a Standalone CIFS server to another

Thats what lgdup.exe on Tools & Apps CD is for

Take a look at this manual on Powerlink

Using EMC Utilities for the CIFS Environment

Rainer

Of course even with lgdup the SID’s are going to be different – that’s how it has to be

It just creates the new localgroups so that emcopy can translate

In your case I would suggest to put the CIFS server in a VDM and replicate that

This way the CIFS server config including the localgroups with the same SIDs are replicated

Rainer

Take also a look at the /lg and /lu options of EMCopy

With those switches. Emcopy will try to map names of local user and groups between source and destination

Note that if you use LGdup to recreate local users on dst they will have different SIDs as Rainer said and also you will have to initialize their password

Claude

Also, when grabbing any of the CIFS tools (such as LGDUP), look instead to https://support1.emc.com as noted in the following post:

https://community.emc.com/message/585136#585136

This will assure you are always running the latest.

Thanks for all the help sofar. I tried with LGDUP but still not able to access files on the second datamover.
Maybe I have to clarify my setup and requirements:

Requirements:
- Standalone CIFS server for 2 single applications, each app using one CIFS-share
- For DR purposes replication is required
- during real Disaster IP-space on VNX2 is the same as on production
- during disaster-testing files should be readable from VNX2. During testing VNX1 cannot be switchedover and have to stay 7x24 in production.
- Files are classified, and may only be read by one specific CIFS user

Setup

- I have a primary VNX, VNX1 with a VDM and a standalone CIFS-server + filesystem + share inside the VDM, called VDM1
- This VDM1 and the underlying filesystems are replicated to a secondary VNX: VNX2.
- On the secondary VNX2 a standalone CIFS server is created on server_2
- A share is created on VNX2 using MMC of the replication target (i.e. /root_vdm_2/filesystem/directory).

The problem is that the VNX2 read-only share can be mapped from Windows, but files cannot be read, due to the fact that the SID of the user on VNX2 is different from the SID on VNX1.

I have tried to copy users with LGDUP. This seemed to do the job, however the files are still not readable, probably due to the fact that SIDs are not the same.
Also tried to copy the db.5.localgroups file over from VNX1 to VNX2 (and change the CIFS-server name), but this gave some strange behaviour (not able to run MMC anymore against the VNX2), so restored old file.

Question still remains: how to copy users with SIDs from one standalone Celerra CIFS server to another standalone Celerra CIFS server?
And other questions I have: how to check a SID of a standalone user. The server_cifssupport gives no output on secmap (probably not used with standalone), same for usermapper. Other server_cifssupport commands do not give info on a user either (probably also due to standalone).

Thanks for any further help!
Jan

well - thats the way Windows security works

Each server has a unique ID and SID's for localgroups contain that ID

So another server has to have different SID's

Only exception are well-known SIDs like everyone.

We arent going to circumvent Windows security with VNX.

Having two CIFS servers on the net with the same SIDs and machine accounts would create other problems

PLEASE DONT hack around internal config files - they arent meant to be copied or edited.

For your case - just replicate the CIFS server as part of a VDM.

On a real desaster you can then just failover and the DR CIFS server has the same localgroups, share's SIDs, ...

DR testing is more work. It can be done with writeable snapshots provided you can temp. seperate your prod. and DR environment to aboid problems with duplicate CIFS server enviroment.

If you are attending EMC World in May - a colleague of mine does a presentation there with exactly this scenario and a customer use case.

Rainer

As Rainer already suggested, I will be presenting a solution to a similar problem (albeit for Domain CIFS servers) at EMC World. The session is called "VNX/CTA Disaster Recovery and Testing". You are welcome to attend.

As to the problem at hand, I agree with Rainer that the way you are trying to access data violates Windows security. In your case, the Administrator@server_2@VNX1 has no rights to the data owned by Administrator of VDM@VNX. The reason why those two are different are basic -- Administrator SID is constructed from the Windows server SID, with a '-500' at the end. Same rule applies to Domains, which, btw, is one reason why renaming Administrator account doesn't provide better security -- the SID stays the same no matter what. But I digress…

In order for you to get access to the data, you need to do one of two things:

a. Change permissions on the data to allow Admin@server_2@VNX1

b. Or, bring VMD@VNX into loaded state

No one would be changing all data security when it would be overwritten anyway, so one way to go about that is, again, as Rainer said, to take a writable checkpoint of the replicated filesystem, and follow that by taking ownership of the data, and changing the ACLs in it.

The other way around the problem is to stop and delete VDM replication (it won't delete VDM@VNX1), and keep data filesystems replicated. That will switch the VDM@VNX1 to 'loaded' state, and loading the Standalone CIFS server up, thus allowing one to connect as Administrator@VDM@VNX1 to that CIFS server and access the data the normal way. You will have two identical Standalone servers (down to the SIDs), with filesystems still replicating from VNX to VNX1.

Just keep in mind that normal VDM small print applies -- IP interface names must match between VNX and VNX1. However, IP addresses attached to those interfaces don't have to match. In your case, that is all you need to do -- as the Standalone won't be confusing AD with dual name that exists in two places at once. You may, however, turn off DNS auto-update (set parameter dns.updateMode to 0)

Best regards,

--Mark Rogov

Even without a domain - if you go that route for a DR test to have both servers active at the same time with the same. Name you HAVE to have the networks separated for that duration

Otherwise you risk confusing clients, browsing, WINS, ....

You could get prod clients connecting to the DR server by accident and get split-brain like problems

feedback ?

Please let us know what you end up going to implement.

Rainer