How to cable up VNX SP Ports (Dual Fabric topology)

So your VNX has two SP’s and you have two fabric switches.  You already know you have to connect each SP to each fabric for resilience, but you’re still a bit confused.  Fear not.  Use this as a guide.  It can be used no matter how many front-end port modules and SFP’s you have so that you get it right first time for all your designated Storage Ports, Mirrorview Ports, Sancopy Ports required for your project.  The FC Switch Ports you choose are not set in stone, but keep it the same on each side at least.

 What’s important is that the correct SP port, goes to the correct switch.

When you know you’ve got it right, you can get verify the WWN in Unisphere corresponds with the WWN logged in on the FLOGI database on the switch to check before you create the requisite fcaliases etc.


It’s much easier to build it right first time than sort it out afterwards.



Inject Administrators/Full Control permissions into inaccessible folders.

Note:  This can also be used to inject Everyone/Full Control, or a specific user, using the username or SID.  The Administrators Group SID is always S-1-5-32-544.  Other well-known SIDs are listed here.

Download the command line version of SetACL.exe from here.  Like all the best things in life, it’s free.

Open a command prompt as Adminstrator (right click cmd.exe, run as admin)

setacl -on “C:\Private No Entry” -ot file -actn ace -ace “n:Administrators;p:full” -rec cont_obj -ignoreerr

The “Private No Entry” folder should now have Administrators, Full Control Permissions.  If not, don’t fret, read on…

The following command gives Administrators the “dream ticket” to accessing all data by setting ownership to Administrators on all folders and files and forcing subdirectories to re-inherit inheritable Administrators:Full Control permissions from the parent.

setacl -on “C:\Private No Entry” -ot file -actn setprot -op “dacl:np;sacl:nc” -rec cont_obj -actn setowner -ownr “n:S-1-5-32-544”

If you still receive “Operating System Message:Access Denied” or similar, then you’ll need to take a robocopy of the “inaccessible” data using the /B switch to exploit OS Backup Right, leaving permissions behind using /COPY:DAT (instead of /COPY:DATSOU or /COPYALL) then repeat the process above on the copied data instead.

robocopy “C:\Private No Entry” “T:\Cracked Data” /B /COPY:DAT /E /NP /R:1 /W:1

Now view the Inherited permissions on the copied data…  You’ll see it has a whole bunch of new, open permissions that it’s got from the parent folder T:.

cacls “T:\Cracked Data”

The cracked data could be robocopied back over the original inaccessible source data using /MIR /COPYALL /SEC /SECFIX switches if required.  If it doesn’t allow it, then note that I have successfully robocopied an empty folder over the top of an inaccessible folder before using just /MIR  (in order to delete it), then robocopied the cracked data back into place, e.g.

robocopy “T:\Empty Folder” “C:\Private No Entry” /MIR /B

robocopy “T:\Cracked Data” “C:\Private No Entry” /MIR /SEC /B

Finally, if you want to re-harden the folder whilst retaining the access you’ve granted Administrators, then use the following commands…

Presently, access has been attained via inherited permissions so before removing inheritance, first inject a non-inherited ACE that allows administrators access, i.e.

setacl -on “C:\Private No Entry” -ot file -actn ace -ace “n:S-1-5-32-544;p:full” -rec cont_obj

Verify the Administrators:Full Control permissions are present on the folder

cacls “C:\Private No Entry”

Finally it is safe to remove inheritance without losing access (strictly speaking, you are “protecting the child object from inherited permissions on the parent object”)

setacl -on u567149 -ot file -actn setprot -op “dacl:p_nc;sacl:p_nc”

This sequence of commands can be used to copy users home directories that are typically hardened to only permit the user themselves access to the data contained within.  If you are using it to migrate home dierctories, there is a loop to re-apply user-specific permissions to each homedirectory afterwards here


RecoverPoint Journal LUN sizing

The Journal size is a question of the required protection window (a Business requirement) and the incoming write rate of the production application.  Whilst the Recovery Point Objective might be known, the incoming write rate of a newly deployed app may not be, making sizing of journal LUNs a bit “finger in the air”.  EMC provide a guideline value of 20% in this instance, but it has no real foundation.

The basic calculation is ( protection window in seconds * write rate in seconds ) / 0.7
The division by 0.7 is because roughly 70% of the journal is used for replication images.

For example, if the business requires 1 day of images and the average write rate by the application is 1MB/s you will need a minimum of about 125GB journal to support it.  RecoverPoint supports automatic journal LUN creation during configuration of a Consistency Group if you don’t have enough information to manually size the journal LUN up front.

During a recent deployment of RecoverPoint to support replication of LUNs to remote storage, solely for the purposes of failover, EMCs response was as follows.  Please note that in this scenario, there was no requirement for the “killer functionality” of RecoverPoint, namely point in time recovery using the journaled changes in Consistency Groups.  That’s not to say it won’t become a requirement later on however.

The Raid group in question would definitely be adequate to start replication, but whether it is enough to meet the business requirements, we cannot say.

Sizing aside, remember that it is very important to use a dedicated Storage Pool/RAID Group of physical disks that is entirely separate to ones used for your data LUNs and RecoverPoint Repository LUN.


Cisco MDS Cheat Sheet

A more complete set of commands for use on MDS switches, with a useful set of commands at the top for exporting useful information (by logging session output of PuTTY terminal).  Note that using a ? after any command will show possible commands.

Export useful information

show switchname (display hostname on network)

show flogi database (shows wwn of fc connected hosts logged in to the switch ports)

fc1/1      60      0xad04d1       50:05:07:61:13:61:a6:33 51:01:07:63:11:20:a6:33
fc1/2      60     0xad0012       50:05:07:63:12:13:51:37 50:01:07:61:12:03:55:37

show interface description (shows description field for each physical port)

show interface brief (shows ports in errDisabled state)

Interface Description
fc1/1         L5500_CyberfellaTD1_1_A
fc1/2        L5500_CyberfellaTD2_1_A

show vsan (display vsans configured)

show zone vsan 10 (display zones in vsan)

show zoneset vsan 10 (display zoneset, zonenames and wwns in zones)

show fcalias vsan 10 (display human friendly alias for each wwn in all zones in vsan 10)


Before you can create your zones, the device connected to the fc switch will need to flog in so you can see its wwn.  Before it can do that, the port itself will need to be opened/enabled.

conf t

interface fc1/21       (where 21 is the port number)

no shutdown           (obviously!)


more here


If you have to do some CISCO zoning at the command line here are a few of my favorite commands;

original cisco doc here

To create an alias:

conf t
fcalias name {alias_name} vsan {vsan number}
member pwwn {wwid}

To create a zone:
conf t
zone name {zone _name} vsan {vsan_number}
member {alias_name}
member {alias_name}

To add it to the zoneset:
conf t
zoneset name {zoneset_name} vsan {vsan_number}
member {zone_name}

To activate the zone/zoneset:
conf t
zoneset activate name {zoneset_name} vsan {vsan_number}

Save the configuration
copy running-config startup-config

Displaying Zone Information

You can view any zone information by using the show command. If you request information for a specific object (for example, a specific zone, zone set, VSAN, alias, or even a keyword like brief or active), only information for the specified object is displayed. If you do not request specific information, all available information is displayed. Table 4-1 lists the show commands and the information they display.

Table 4-1 show zone and show zoneset Commands

show Command
show zone

Displays zone information for all VSANs.

show zone vsan 1

Displays zone information for a specific VSAN.

show zoneset vsan 1

Displays information for the configured zone set.

show zoneset vsan 2-3

Displays configured zone set information for a range of VSANs.

show zone name Zone1

Displays members of a zone.

show fcalias vsan 1

Displays fcalias configuration.

show zone member pwwn 21:00:00:20:37:9c:48:e5

Displays membership status.

show zone statistics

Displays zone statistics.

show zone statistics read-only-zoning

Displays read-only zoning statistics.

show zoneset active

Displays active zone sets.

show zoneset brief

Displays brief descriptions of zone sets.

show zone active

Displays active zones.

show zone status

Displays zone status.

show zone

Displays zone statistics.

show running

Displays the interface-based zones.


Deleting Windows data where the path length exceeds 260 characters

After migrating Windows data, it can be a royal pain cleaning up the source data using del *.* /s /q /f, especially when the path length exceeds 260 (or thereabouts) characters.  You can manually shorten the folder names and keep trying, but this may be time consuming, tiring and ultimately futile.

The simplest way I’ve found to reliably delete data, irrespective of path length, is to use robocopy.

  1. cd into the directory that you want to empty
  2. create a new empty subdirectory called empty
  3. rename all other adjacent folders 1, 2, 3, 4 etc if possible
  4. robocopy empty 1 /mir /r:1 /w:1
  5. repeat for each adjacent folder, 2, 3, 4 etc.



Robocopy leaves some NTFS permissions behind?

And so does emcopy and icacls /save & /restore doesn’t work either…

Googling doesn’t help – every solution that promises to work, doesn’t.



Sorry for shouting, but I’m really rather excited to have cracked this major show stopper for my clients data migration.  The /B switch uses the Backup right to perform the copy.  That’s presumably running with system level privs, rather than my meager admin account in cmd run as administrator.  Magic.  Data integrity restored!  Professional reputation saved!

Note: Use /TIMFIX with /B to correct non-copying of datestamps on files, resulting in 02/01/1980 datestamps on all files copied with /B Backup rights.


ISL configuration on Cisco MDS

Assign hostname to switch

switchname <hostname>

Create Inter-Site Links (join two switches together to share zones)

conf t
trunk protocol enable #to enable trunking protocol
conf t
no trunk protocol enable #to disable trunking protocol

trunk protocol auto #to set trunking in auto mode . The preferred conf for CISCO MDS switches is (on) (auto) – one switch enabled, second is auto.

1. Connect 2 switches with FC cable on ANY port
2. In each switch, change port mode to TE:
show interface fc1/1
show running-config interface 1/1 # to see a current configuration
config t
interface fc1/1
switchport mode auto /on /off #will automatically set the port in TE mode in case it was previously set in another mode

3. Trunking ports should remain in VSAN1
4. Create new VSAN (same name and number) on both switches.
5. On both switches, run:
config t
interface fc1/1
switchport trunk allowed vsan 2-4 (To configure an allowed-active list of VSANs for an interface)
switchport trunk allowed vsan add 6 (Expands the specified VSAN 6 to the new allowed list)
no switchport trunk allowed vsan 2-4 (Disallow VSANS from being trunked)
no switchport trunk allowed vsan 5

One important note: you should create a VSANs BEFORE you allowing trunking on them –
otherwise trunking port will be automatically disabled due to VSAN mismatch.
Same problem can occur, if trunking interfaces are located in different VSANs
(for example, fc1/1 on switch A is in VSAN 2, while fc1/9 on switch B is in VSAN 3).


Zone configuration on Cisco MDS

This post covers the commands used to display zone configuration, activate/deactivate zones, create/delete aliases for fibre attached devices, create/delete zones and create/delete zonesets and copying the configuration to the running configuration.

By default 3 VSANS in MDS Switches
show vsan         -3 zones, 1 (active), 4079 (evfp_isolatied_vsan), 4094 (isolated_vsan)

Enter configuration mode
config t
vsan database
vsan 1 suspend

Create new VSAN
vsan 100
Give it a name
vsan 100 name ProdVSAN100
show vsan

You can see VSAN100 is in active state
Add physical interface
config t
vsan database
vsan 100 interface fc1/1    (Add individual interface)
vsan 100 interface fc1/2-16  (Adds range of interfaces)

Enable Interfaces/Ports
config t
interface fc1/1   (exit and Repeat for other interfaces)
no shut    (Enables interface – shut disables)

show flogi database            (Check what wwn’s have flogged in)
show fcns database vsan 100   (State of VSAN100)

Disable the default zone
no zone default-zone permit vsan 100

Create the FC-Alias for Zone
fcalias name SUN_HBA1 vsan 100
member pwwn 10:00:00:00:c9:b0:b9:8e

fcalias name Win_HBA1 vsan 100
member pwwn 10:00:00:00:c9:b0:b9:8e

fcalias name VNX_SPA vsan 100
member pwwn 50:06:01:6b:08:60:10:07

show fcalias

Create the Zone
zone name WIN_HBA1_VNX_SPA vsan 100
member fcalias VNX_SPA
member fcalias Win_HBA1
zone name SUN_HBA1_VNX_SPA vsan 100
member fcalias VNX_SPA
member fcalias SUN_HBA1
show zone

Create the Zoneset
zoneset name Cloud_Zone vsan 100

Activate the Zoneset
zoneset activate name Cloud_Zone vsan 100

Save the configuration
copy running-config startup-config

Validate the Zone configuration and show the active zone
show zoneset            (Displays Zoneset, with Zones inside and aliases inside)
show zoneset active     (Displays same but connection status indicated also)

Deactivate the zoneset
no zoneset activate name Cloud_Zone vsan 100

Delete the zoneset
no zoneset name Cloud_Zone vsan 100

Delete the zones
no zone name WIN_HBA1_VNX_SPA vsan 100
no zone name SUN_HBA1_VNX_SPA vsan 100

Delete the Aliases
no fcalias name SUN_HBA1 vsan 100
no fcalias name Win_HBA1 vsan 100
no fcalias name VNX_SPA vsan 100

show zone   (Zone not present)
show fcalias (Alias not present)


Finding SIDs that haven’t changed after SetACL

This post follows on from a previous post sidmaps and setacl describing how you can use SetACL with a SID map generated using dsquery to translate sidHistory attributes to primarySIDs for migrated groups used in the permissions on your data.  It is used in the final stages of a domain migration so cut the reliance on the continued existence of the old domain controllers in order to verify that the sidHistory attributes of migrated groups in the new domain still correspond with a valid object in the old domain (often referred to as ‘lookback’ or ‘reachback’).

Before an old domain can be decommissioned, the SIDs securing the NTFS folders need to be switched to use only the primary SIDs of the migrated groups.

Once a first pass of SetACL with a sidmap has been run, you’ll need to check that there are no legacy SIDs still being used to secure any folders.

To achieve this, I re-run an export of the security using a command similar to

icacls E:\rootfolder /save H:\exports\E_export.txt 

then split the potentially large log file up into 10Mb pieces using a free filesplitter such as the one available here

I open each file and re-save in ANSI encoded format using Notepad++ available here Notepad++ This is necessary for the subsequent pattern matching steps to work correctly.

I make sure I have GNUWin32 utilities installed available here GNUWin32 so that I can use powerful command line utilities such as cut, sort and uniq ordinarily only available in Linux/UNIX, in Windows.

The following command is then used to strip the old sids from the files and create a new unique list of old SIDs

cut -d; -f6 file_01(10).txt | cut -d) -f1 | findstr S-1-5-1-123456789 | sort | uniq >> sidlist.txt      

(can use | wc -l to just count lines)

I repeat the command on the first file of the set of ten split files i.e file_01(10).txt, for the following fields (we’ve already done field 6 i.e. -f6)

11, 16, 21, 26, 31, 36, 41, 46, 51, 56 and so on (increments of 5) until I get nothing more out for file_01(10).txt before moving on and repeating the process for file 2 i.e file_02(10).txt and so on until I’ve exhausted all 10 files.  This doesn’t take as long as it sounds.  It’s even quicker if you put it in a loop like this…

REM Requires GNUWin32 installed as a prereq.
REM Use fsplit.exe to break large icacls exports into 10MB pieces.
REM Usage Example: extractsids.bat exportfile_01(16).txt 1552345678
SET /a i=6
IF %i%==56 GOTO END
echo Extracting sids matching %2 from field %i% in %1…
cut -d; -f%i% %1 | cut -d) -f1 | findstr %2 | sort | uniq >> %1_sidsextracted.txt
SET /a i=%i%+5
sort %1_sidsextracted.txt | uniq > %1_%2_extractedsids.txt
if exist %1_sidsextracted.txt | uniq > %1_%2_extractedsids.txt
if exist %1_sidsextracted.txt (
del %1_sidsextracted.txt
) else (
echo “Somethings gone wrong.
echo Done! Extracted sids written to %1_extractedsids.txt

I then re-sort and unique the list again to end up with my final list of SIDs that were not changed as part of the initial Re-ACL process. (Step is included in batch file above).

sort sidlist.txt | uniq > unchanged_sids.txt

If I need to identify what users or groups these unique SIDs correspond to in AD, then I can use the free tool available here sidtoname.exe in conjunction with the following batch file that I’ll call get_names.bat

@echo off
REM Usage:  From a command line…
REM groupnames.bat unchanged_sids.txt > names.txt
REM Dependencies: sidtoname.exe
for /f %%a in (%1) do (
sidtoname.exe %%a

And there you have it.  A list of groups whose SID’s were not changed after an initial pass of SetACL with a sidmap.  You now need to take the list of sids or the list of groups and determine the sidHistory and primarySIDs of them, then append them to your original sidmap before re-running another pass of SetACL.  Note that the groups listed in names.txt could be user names as well as group names (or aliases too).  They will be conveniently prepended with a label of User, Group or Alias accordingly.





Re-ACL of inter-domain migrated data

When migrating from one domain to another (usually new) domain, the users and groups are migrated so as to retain their historical SID.  This is so that the migrated account in the new domain can still access resources in the old domain that were secured against that users unique SID or groups to which that user was once a member.  When a user account is migrated, a new account is effectively created with a new, unique SID, but the old SID is also retained.

This is convenient so that everything continues to “hang together” in terms of newly migrated users being able to access new data and old data pending its inevitable migration to file servers or NAS in the new domain.

Once the data is migrated to the new domain, then the ACL’s will still likely contain ACE’s of user and group SIDs from the legacy domain.  The migrated users will still be able to access this data provided the old domain continues to exist for the purposes of authenticating old SIDs but at some point, the old domain will likely be scheduled for decomissioning to free up money and space associated with cooling, electricity and ongoing support overheads.  Another option would be to virtualize an old DC and have done with it.

The legacy user and group SID’s contained in the ACE’s will need to be translated to the primary SIDs of the new migrated users and groups to remove the need for legacy DC’s to remain in the new environment.  This can be done using SetACL – the freely available tool mentioned in other posts such as Removing Orphaned SIDs.

The following prose is a combination of my own notes and those found on the Helge Klein website where SetACL can be downloaded.

Migration – the Flexible Way

SetACL 3 comes with a more flexible way of handling permissions migrations. Its enhanced migration engine can be used to migrate intra-domain, inter-domain or any mix of the two. To start a migration using the flexible model use a command line similar to the following:

SetACL -on D:\Data -ot file -actn trustee -trst csv:C:\temp\mappings.csv;ta:repltrst -rec cont

This instructs SetACL to copy permissions between individual users or groups for the D:\Data directory tree. Which accounts the migration is performed for is read from a simple CSV file, mappings.csv in the example, whose contents might look like this:


or like this… (both formats are supported, I prefer this one i.e. sddl format)


As you can see, the system is flexible, powerful and easy to use. All you have to do is create a mapping table pairing old account with new account. If you do not want to do that or if you think it is just too much bother: the simpler method presented above still works and is still considered useful in many scenarios.

Command reference

Working example

Back up directory security first.  Always use a starting folder, not the root of the drive.  The restores do not work to the root of a drive as the export file has an empty first line that upsets the restore process.  This means you may need to back up each top level folder individually so that your restores would work or you can just delete the first empty line (but be aware you’ll not recover its permissions and applying them manually will cause them to subsequently ripple down through the tree (no)thanks to Windows’ behaviour.)

icacls D:\sourcedata /save ACL_Dep.txt /T /C    (Traverse and continue on errors )

backups of acl’s can be restored as follows:

icacls D:\ /restore ACL_Dep.txt /c   (continue on errors such as missing files)

Map files can be created as follows.
Dump SID + SID history to a file for Migrated Groups: (change the OU path with the correct one for your AD)

dsquery * “OU=Groups,OU=MigratedGroups,OU=Cromford,OU=UK,OU=DEV,OU=VMFARM,DC=cyberfella,DC=co,DC=uk” -filter “(&(objectClass=Group)(sidHistory=*))” -attr sidHistory ObjectSID -limit 20000 > Sidmapping.txt

Check if –limit option is set large enough given the number of groups in your domain. Perform necessary edits to the sidmapping.txt file until it’s format looks like this (below).


Re-ACL Migrated Group ACE’s from the historical SIDs currently securing the data to the primary object SIDs in the new domain using the freely available SetACL tool.

setacl -on D:\destinationdata -ot file -actn trustee -trst csv:sidmapping.txt;ta:repltrst -rec cont_obj –log reacl_log.txt

The following command will delete any orphaned SIDs (ACE’s that to don’t resolve to any group in AD and thus serve no purpose)

setacl -on D:\destinationdata -ot file -actn delorphanedsids -rec cont_obj


(Obviously your results may vary depending on many variables such as number of folder, files, rows in sid map csv, disk speed, cpu speed, etc)

Exporting ACLs for 128GB filesystem consisting of 30,000 files in 2,750 folders on an HP ProBook CORE i5 laptop took 15 seconds.and processed every file successfully although problems are generally encountered if files have been created using file explorer run as administrator (the ownership changes from the logged on user to admnistrators).

5 new groups were added to the acl’s at the top of the tree and re-exporting the security took 17 seconds (a further 3 seconds)

Re-ACLing the filesystem using a SID Map containing 5 rows to translate ALL ACE’s referencing the newly added groups to a single new group, took 5 minutes, 45 seconds.

Copying the folder structure only but leaving all files behind (create duplicate empty folder structure with security using emcopy), took 14 seconds.

Re-ACLing the empty folder structure (2,750 folders), avoiding the overhead of scanning and re-acling 30,000 files took 25 seconds.

It is therefore recommended that re-acling take place on a duplicate empty folder structure and data (files) are subsequently copied into it using emcopy with the /nosec switch.

For large filesystems, say over 1TB, you may want to process each top level folder as its own individual job, looping through all top level folders sequentially.  It’s definitely my preferred approach with pretty much everything, not just setacl.  You can use a for loop to do this, e.g.

for /f %%f in (‘dir s:\ /ad /b’) DO setacl.exe -on “d:\root\%%f”  -ot file -actn trustee -trst csv:sidmap.txt;ta:repltrst -rec cont_obj


As is often the case, the real-world (the source of all my blog posts) presents some unforseen issues around the use of these complex tools, and setacl appears to have an issue whereby re-acling using the trustee action above (the same method as documented on Helge Klein’s website) also performs a reset on the inheritance attribute, potentially opening up hardened subfolders where the original inherited ace’s have been partially retained and inheritance turned off.

The following sequence of commands appear to correct the issue by re-breaking inheritance, removing inherited ace’s, applying specific permissions to the subfolder before turning inheritance back on on the parent.

Consider the following structure.  T:\level 1\level 2\level 3  where level 2 inherits from level 1 but level 3 stops inheriting and has its own permissions set.  If these permissions were originally ace’s that were inherited, then re-permissioning can reset inheritance.  The following sequence of commands seems to correct it.  Your mileage may vary.

setacl -on “t:\level 1\level 2” -ot file -actn setprot -op “dacl:p_nc;sacl:p_nc”          (Protection, No Copy Inherited ACEs)

setacl -on “t:\level 1\level 2\level 3” -ot file -actn ace -ace “n:S-1-5-21-12345-12345-12345-1234;p:full” -ace “n:S-1-5-21…. and so on.

setacl -on “t:\level 1\level 2\level 3” -ot file -actn setprot -op “dacl:p_nc;sacl:p_nc”  (Protection, Remove Inherited ACEs)

setacl -on “t:\level 1\level 2” -ot file -actn setprot -op “dacl:np;sacl:np”                  (No Protection)