EMC Celerra NAS Device Issue

We are currently in the pilot phase of a migration and we seem to be having some issues around the NAS head devices which are EMC Celerra.  The users are not able to access their file share post migration getting an access denied message.  We are currently using QMMAD 8.8 and migrating SIDHistory.  We have not processed the NAS heads yet we were hoping to use SIDHistory.  Has anyone seen any issues that we should be aware of with the EMC Celerra devices.

Thanks,

Ray

  • I see. Ray, is the SID History not working in general, when accessing the resources, or is it not working for some users and groups only?

  • Sid History appears to be working for most of the users and appears to be no issue with the Windows servers but we have a subset of users accessing NAS devices that appear to have these issues.  We have some users accessing the NAS devices with no issues but then there are some that are getting access denied.

    Ray

  • Ray, have you tried to find a pattern and to narrow it down?

    eg. all those users have no sid history populated?

    or they were given access based on group membership, and not explicitly?

    btw this is a good test - if target user gets access denied go and give the SOURCE user explicit rights and see what happens, this should bring you one step closer to resolution.

  • All,

         We have some further developments it appears that this is not as widespread as we thought.  But we did find the users that are having issues are a member of a domain local group in the source domain and the group was given NTFS permissions to this folder.  The domain local group was moved to the target domain but it does not appear to be helping.  Shouldn't sidHistory allow us to access these folders based on permissions to the domain local group.

    Ray

  • SidHistory for Domain Local groups will not cross the trust boundary. To successfully maintain access during they migration you will need to process the directory that the server is a member of using Active Directory Processing Wizard to update the domain local groups with Target security princables.

  • Jeff,

    I have been following this thread concerning DL Groups.  When using the ADPW I create a scope, then select the group in question where it resides according to the thread.  Which in this case still resides in the source?

    What if I use the famous check box in a migration session "  Add source members to the corresponding target groups"  Would this elevate from using the ADPW?

  • Enrico, Jeff says "you need to use Active Directory Processing Wizard to update the domain local groups with Target security principals", but what you are proposing will simply add source users into the target group:

    https://support.quest.com/SolutionDetail.aspx?id=SOL45738

  • My bad what i meant to say "When using the ADPW I create a scope, then select the group in question where it resides according to the thread. Which in this case still resides in the source?"  Basically I run ADPW against the Source DL?   Forget about the group option  Add source members to the corresponding target groups.

    Regards

  • Oh, you want to run the wizard against the source AD, so ADPW replaces the source users with target users or adds an entry for the target user?

  • Hi Wally,

    This is what Jeff mentioned.

    SidHistory for Domain Local groups will not cross the trust boundary. To successfully maintain access during they migration you will need to process the directory that the server is a member of using Active Directory Processing Wizard to update the domain local groups with Target security principles.   

    Just wondering since the server will still be in the source domain and the DL have been migrated over into the Target domain.  Then I would run the ADPW against that DL but in the SOURCE Domain where the server still resides temporarily.  These last two questions will be asked to our PSO since what I stated in the last discussion our migration strategy has changed somewhat.