Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > SRM Windows
The SRA is called by the SRM service and therefore inherits the user account from the SRM service running on the respective SRM server.
The account that is used by the SRM service can be verified by examining the SRM service details in the Windows Server “Services” console. The following example shows how to perform this verification in Windows Server 2008 R2. While there are some minor differences between Windows Server editions, the basic process remains the same.
This process must be followed for each SRM server to correctly identify the user accounts that will require Symmetrix authorizations roles assigned to them. Once the accounts have been identified, each account needs the “Storage Admin” role assigned to it on every PowerMax array that has Symmetrix Authorizations enabled and that has replicated devices in use by VMware SRM.
For example, here is a typical environment:
In order for both SRDF SRA’s to function properly the following roles on the following VMAX arrays are necessary:
On PowerMax 194900281:
“Storage Admin” role to user D:EBC\srmuser1
“Storage Admin” role to user D:EBC\srmuser2
On PowerMax 194903603:
“Storage Admin” role to user D:EBC\srmuser1
“Storage Admin” role to user D:EBC\srmuser2
On PowerMax 194903785:
“Storage Admin” role to user D:EBC\srmuser1
“Storage Admin” role to user D:EBC\srmuser2
On PowerMax 194900474:
“Storage Admin” role to user D:EBC\srmuser1
“Storage Admin” role to user D:EBC\srmuser2
If the local system accounts are running the SRM services, the user accounts entered into the symauth database would instead look like H:SRM-SERVER1\SYSTEM and H:SRM-SERVER2\SYSTEM for SRM server one and two respectively.
In the case of 3-site SRDF, both user accounts will need to be authorized as “Storage Admin” on the bunker target site array as well.
Failure to properly set the authorizations will result in failure to complete a test failover or failover in SRM. In the SRDF SRA log file an entry similar to the following will be present:
[09/21 11:47:02 18964 0687 SymmUtil::SymmDevListSync] [ERROR]: Failed SymDevListSync() on Symm [000197700104].
[ERROR]: [SYMAPI_C_AUTHZ_NOT_AUTHORIZED: The caller is
not authorized to perform the requested operation]
If there is ever a question of the user executing the SRA commands, simply run a test failover and when it fails, review the symapi-xxx.log file on the recovery site where the authorization error will be present, indicating the user who does not have permission. This example below is from the same environment as above where the SRM service is running as the local system account:
09/21/2017 11:47:02.850 1632 36672 EMC:EmcSrdfSra
check_user_perms User Authorization Failure for User H:dsib2015\SYSTEM, Group H:dsib2015\SYSTEM,D:BUILTIN\Administrators, SID 000197700104 -- 'BASE' rights not present (minimum necessary role: Monitor)
The SRA is called by a special user on the Appliance, “srm”. This user does not have a normal login or home directory and is only used by SRM. This user is already granted privileges to run the necessary Solutions Enabler commands in the daemon_users file. Unlike SRM Windows, a different user may not be substituted for srm, and thus it is this user that will require authorization.
Because the SRA runs as a container, however, the CONTAINER ID is also the hostname as shown in Figure 194, rather than the SRM Appliance hostname.
Figure 194. Container ID and hostname of the SRDF SRA
When adding an authorization with symauth, therefore, the container ID would be the hostname: H:699cfe7b671f\srm. This presents a unique problem, however, because every time the SRDF SRA is reloaded, a new CONTAINER ID is generated as seen in Figure 195.
Figure 195. Container ID changes after an SRDF SRA reload
Thus, each reload requires a new authorization for srm. To avoid this, Dell recommends a blanket authorization for the SRM user for all hosts using the wildcard: H:*\srm.