Source vCenter Server has duplicate names in a network folder.

During upgrade from vsphere 6.0 to 6.5 you can got the following error:


Source vCenter Server has duplicate names in a network folder.


Please change name of Distributed Virtual Switch or Distributed Virtual Portgroup with following names: {dvSwitch, } to ensure unique names in each network folder before upgrade. Refer to VMwareKnowledge Base article 2147547 for more details.



vSphere 6.5 allows only unique names across all Distributed Virtual Switches and Distributed Virtual Portgroups in the same network folder. Earlier versions of vSphere allowed a Distributed Virtual Switch and a Distributed Virtual Portgroup to have the same name. If you attempt to upgrade from a version that allows duplicate names, the upgrade fails.


After logging to the VCSA over SSH or console, you can easily connect to the PostgreSQL server locally using psql:

/opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB

List entries in the Distributed Virtual Portgroup table by running this command:

select id,dvportgroup_name from VPX_DVPORTGROUP;

List entries in the Distributed Virtual Switch table table by running this command:

select id,name from VPX_DVS;


List entries in the entities table table by running this command:

select id,name,parent_id from VPX_ENTITY;

Note: The parent_id for the conflicting Distributed Virtual Switch and Distributed Virtual Portgroup names. The same parent_id indicates the same network folder. Change only the duplicate names in the same network folder.


Detect duplicate names of Distributed Virtual Portgroups and Distributed Virtual Switches by running the following command:

select id,dvportgroup_name from VPX_DVPORTGROUP where dvportgroup_name in (select name from VPX_DVS group by name) AND dvportgroup_name in (select name from VPX_ENTITY group by name,parent_id having count(*) > 1);



In my case, I have 3 Distribuited Virtual Portgroup Duplicated

Rename Distributed Virtual Portgroups or Distributed Virtual Switches

  • Update the Distributed Virtual Portgroup table by running these commands:

    update VPX_DVPORTGROUP set dvportgroup_name=’dvSwitch_External 1′ where id=

    update VPX_ENTITY set name=’dvSwitch_External 1′ where id=

    update VPX_DVPORTGROUP set dvportgroup_name=’dvSwitch_Vmotion 1′ where id=

    update VPX_ENTITY set name=’dvSwitch_Vmotion 1′ where id=

    update VPX_DVPORTGROUP set dvportgroup_name=
    dvSwitch_Rete_2.X 1′ where id=

    update VPX_ENTITY set name=’dvSwitch_Rete_2.X 1′ where id=

    Note: After running each command, you will see the output as UPDATE 1.

You also could have the Distribuited Virtual Switch, you can update with this command

  • Update the Distributed Virtual Switchtable by running these commands:

    update VPX_DVS set name=’DSwitch 2′ where id=7;

    update VPX_ENTITY set name=’DSwitch 2′ where id=7;

    Note: After running each command, you will see the output as UPDATE 1.

Verify that there are no duplicate names in the same network folder

After you rename the Distributed Virtual Portgroups or Distributed Virtual Switch, verify that there are no duplicate names in the same network folder by running this command:

select id,dvportgroup_name from VPX_DVPORTGROUP where dvportgroup_name in (select name from VPX_DVS group by name) AND dvportgroup_name in (select name from VPX_ENTITY group by name,parent_id having count(*) > 1);

Now should be solved.


Many times we come across when our SM59 RFC connection SAPOSS or other connections related to SAPNet is not working, most of the time due to wrong password, which you we can easily correct with the correct logon data which is as follows(SAP Note 182308):
Language    EN
Client      001
User        OSS_RFC
Password    CPIC


But this is not which I wanted to discuss here. Here we will check the firewall connection and how to create these RFC connections automatically.

Before we proceed, maintaining correct hostname(Use FQDN) and its correct IP that can be reached from outside of you customer network is very important.

So double checking it is best idea.

Scenario 1

In above screen of OSS1, we have SAProuter 1 and SAProuter 2 entry filled, though filling the entry for SAProuter 1 and SAProuter 2 is not mandatory in order to work your OSS connection in SM59…. BUT from your server firewall and SAPNet firewall connection should be allowed.


Lets move to this scenario, where both SAProuter 1 and SAProuter 2 entry is filled with your customer hosts where saprouter is configured.

For discussion sake lets assume the server name is “C” where you are executing OSS1 tcode, and two other servers are host A and host B as mentioned in figure.


The flow will be C -> A -> B -> SAPNet

1. Login to server C and check the port

telnet <A IP/hostname> 3299

You should get response like below


2. Again login to host A  and check port

telnet <B IP/hostname> 3299


Now, we will check in reverse direction for incoming flow

B -> A -> C


1. Login to host B and check port for A

telnet <A IP/hostname> 3299


2. Login to host A and check port for C here you have to check for your application instance number, if it is lets say 40 then

telnet <C IP/hostname> 3240


If any of the above telnet is not working then get in touch with your client network/firewall team and request them to open the port.


In this scenario, we noticed that SAProuter 2 is router which is responsible for first entry point from outside your client network, which means the firewall at host B should be open for SAPNet to enter and at the same time if it is not done earlier then you have to be in touch with SAPNet network team and request them with help of OSS message to allow entry for your host A


Scenario 2

When we fill SAProuter 1 only not the SAProuter 2

This means that in client network host A will be entry/exit point and your application servers will be communicated with SAPNet like this

C -> A -> SAPNet

You have to check your firewall accordingly.


Note 35010 – Service connections: Composite note (overview)


If all these firewall is working fine, the delete all RFC connection related to SAPNet and recreate them as follows (SAP Note 812386)

1. Transaction OSS1 ->Parameters -> Technical settings -> Change mode -> Save. The SAPOSS destination can only be updated by saving.

2. Create the RFC destinations again:


  • Use the following path to create SAPNET_RTCC: SE38 -> RTCCTOOL -> list -> Refresh from SAPNet
  • Use the following path to create SAPNET_RFC: SDCC -> Maintenance -> Refresh -> Session overview
  • SDCC_OSS is created initially when you activate SDCCN. If you then want  to create a new copy of SAPOSS, use the following path:
  • SDCCN -> Goto -> Settings -> Task specific -> RFC destinations -> Change mode -> ‘Create destination to SAPNet R/3 Frontend’


Checkout this wiki for more insight about saprouter at SAPNet.


Hope this will be of help to some of us.

Central user administration configuration in a landscape

Here is the procedure for Central user administration configuration in a landscape:
1) Create Logical systems to all clients for the landscape using BD54 or SALE as comfortable.
2) Attach Logical system to clients using Same.
3) Create RFC connection to relevant systems with the same name as logical system name .
If you Logical system name is SIDCLNT100 for dev then create RFC connection to DEV with same name SIDCLNT100.
4) Let us suppose you Central system: DEVCLNT100 Child system: QUACLNT200
5) Create user CUA_DEV_100 in devclnt100 system
4. Create user CUA_QUA_200 in quaclnt200 system.
Create RFC’s to child systems from central and central to child.
5) Now logon to central system and execute tcode scua to configure cua.
Enter the name of the distribution model: CUA
Press create
Enter ALL Child system RFC’s
Save your entries now result screen will appear
If you expand the nodes for
the individual systems, you normally see the following messages for
each system: .ALE distribution model was saved,. .Central User
Administration activated,. and .Text comparison was started.. If
problem messages are displayed here, follow the procedure in SAP
Note 333441:
6) Setting the Parameters for Field Distribution Enter Tcode SCUM in central system following screen will appearNow maintain your filed distribution and save it.You can use transaction SUCOMP to administer company address data.You can use transaction SCUG in the central system to perform thesynchronization activities between the central system and the childsystems by selecting your child system on the initial screen of transactionSCUG and then choosing Synchronize Company Addresses in the Central System
After you have synchronized the company addresses, you can transfer theusers from the newly connected child systems to central administration.
This is done, as with the synchronization of the company addresses, using
transaction SCUG in the central system. To do this, on the initial screen of
transaction SCUG, select your child system and choose the Copy Users to the Central System button.
You can use the report RSCCUSND from the central system of Central User Administration (CUA) to synchronize the master data of selected users with a child system of the CUA. The report sends the master data (including role and profile assignments) to a child system of the CUA.

If master data exists in the child system for the user sent, it is overwritten.
1. Start report RSCCUSND (for example, using transaction SA38).
2. In the Receiving System field, specify the child system to which you want to send the user data.
3. You can use the fields User and User Group to restrict the number of users.
4. Specify the data that you want to distribute under Distribution Options.
5. Choose Execute.

Configure SQL Server Database Mirroring Using SSMS

My test environment consists of two separate VM’s running VM Workstation with Windows 2008 R2 Datacenter Edition and SQL Server 2008 R2 Enterprise named appropriately Principal and Mirror. The SQL Server and SQL Server Agent Services accounts are running as domain users (DOMAIN\User). Windows Firewall is OFF for the sake of this example.

I created a database on the Principal SQL Server instance and named it TestMirror. The recovery model is set to FULL RECOVERY.

1st step: Issue a full backup of the database.

BACKUP DATABASE TestMirror TO DISK = ‘C:\Program Files\Microsoft SQL


2nd step: Issue a transaction log backup of the database.

BACKUP LOG TestMirror TO DISK = ‘C:\Program Files\Microsoft SQL


Below are the two files in the file system:

3rd step: Assuming you have the backup folder shared on the Principal Server and you can access it from the Mirror Server, you will need to restore the full backup to the Mirror server with the NORECOVERY option.

RESTORE DATABASE TestMirror FROM DISK = N’\\Principal\Backup\Backup.bak’

WITH FILE = 1, MOVE N’TestMirror_log’ TO

N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TestMirror_1.ldf’,


4th step: Restore log backup also with the NORECOVERY option.

RESTORE LOG TestMirror FROM DISK = N’\\Principal\Backup\Backup.trn’



Now it’s time to dig down and configure Database Mirroring. From the Principal server, right click the database and choose “Tasks” | “Mirror” or choose “Properties” | “Mirroring”.

Click the “Configure Security” button and click “Next >” if the Configure Database Mirroring Security Wizard intro screen appears. The next screen should be the Include Witness Server screen:

This is where you would configure a witness server for your mirroring, but since we’re just configuring a basic mirror we will skip this part. However, if you are configuring mirroring in an Enterprise environment it is recommended you configure a witness server because without one you will not have synchronous automatic failover option.

Select “No”, then click “Next >” to continue the process.

The next screen will give you options to configure the Principal Server Instance:

Here we will be creating our endpoint, which is a SQL Server object that allows SQL Server to communicate over the network. We will name it Mirroring with a Listener Port of 5022.

Click the “Next >” button to continue.

The next screen will give you options to configure the Mirror Server Instance:

To connect to the Mirror server instance we will need to click the “Connect…” button then select the mirror server and provide the correct credentials:

Once connected, we also notice our endpoint name is Mirroring and we are listening on port 5022.

Click “Next >” and you’ll see the Service Accounts screen.

When using Windows Authentication, if the server instances use different accounts, specify the service accounts for SQL Server. These service accounts must all be domain accounts (in the same or trusted domains).

If all the server instances use the same domain account or use certificate-based authentication, leave the fields blank.

Since my service accounts are using the same domain account, I’ll leave this blank.

Click “Finish” and you’ll see a Complete the Wizard screen that summarizes what we just configured. Click “Finish” one more time.

If you see the big green check mark that means Database Mirroring has been configured correctly. However, just because it is configured correctly doesn’t mean that database mirroring is going to start…

Next screen that pops up should be the Start/Do Not Start Mirroring screen:

We’re going to click Do Not Start Mirroring just so we can look at the Operating Modes we can use:

Since we didn’t specify a witness server we will not get the High Safety with automatic failover option, but we still get the High Performance and High Safety without automatic failover options.

For this example, we’ll stick with synchronous high safety without automatic failover so changes on both servers will be synchronized.

Next, click “Start Mirroring” as shown below.

If everything turned out right, Database Mirroring has been started successfully and we are fully synchronized.


If Database mirroring did not start successfully or you received an error here are a few scripts to troubleshoot the situation:

Both servers should be listening on the same port. To verify this, run the following command:

SELECT type_desc, port

FROM sys.tcp_endpoints;

We are listening on port 5022. This should be the same on the Principal and Mirror servers:

Database mirroring should be started on both servers. To verify this, run the following command:

SELECT state_desc

FROM sys.database_mirroring_endpoints;

The state_desc column on both the Principal and Mirror server should be started:

To start an Endpoint, run the following:

ALTER ENDPOINT <Endpoint Name>


AS TCP (LISTENER_PORT = <port number>)

FOR database_mirroring (ROLE = ALL);

ROLES should be the same on both the Principal and Mirror Server, to verify this run:


FROM sys.database_mirroring_endpoints;


To verify the login from the other server has CONNECT permissions run the following:


CONVERT(nvarchar(38), suser_name(SP.grantor_principal_id))





FROM sys.server_permissions SP , sys.endpoints EP

WHERE SP.major_id = EP.endpoint_id

ORDER BY Permission,grantor, grantee;


You can see here from the State and Permissions column that the user has been Granted Connect permissions.

Group Managed Service Accounts alias gMSA

This article will show the process I did to get my managed service account registered for using services like SQL and Task Scheduler.

Managed service accounts have been around for a while but was limited and only worked in the local security context of the windows server. Which meant that you couldn’t use the same account in a cluster of servers.

Usually only limited to Task Scheduler or simple applications.

Please read the following for a quick view on how the old technology worked for Managed service accounts:

Windows 2012 introduced Group Managed Service Accounts which meant, that it could be shared between servers this is great news and shows potential for other applications Like SQL 2012.

I used the following TechNet article to setup my first Group Managed Service Account which I’m going to use for SQL 2012: (Please look for my next blog post on how I installed SQL 2012 with my group managed service account.)

Ok let’s start


Please read the requirements from the article above. I’m only going to highlight the high level requirements.

To enable Group Managed Service Accounts Windows PowerShell is used and it requires to be run from a 64bit instance. I had a Windows 2012 Domain controller in my test environment so using the PowerShell from that server was sufficient. You also require the powershell AD Tools to be installed on the machine you are using.

Before you start

Before you start creating the group managed service account you need to know if the following:

  • Does the application service support gMSAs
  • Does the service require inbound or outbound authentication
  • The computer account names for the member hosts for the service using the gMSA
  • The NetBIOS name for the service
  • The DNS host name for the service
  • The Service Principal Names (SPNs) for the service
  • The password change interval (default is 30 days).

Step 1: Provisioning of group Managed Service Accounts

You can create a gMSA only if the forest schema has been updated to Windows Server 2012, the master root key for Active Directory has been deployed, and there is at least one Windows Server 2012 DC in the domain in which the gMSA will be created.

Important: Master root key is the tricky part. You can force the creation but when the master root key is created you’ll need to wait for AD Replication to complete. Will take up to 10 hours to complete just enable it and leave it for the next day.



  1. Check if a KDS root key exists “Get-kdsrootkey”
  2. If none exist create a new one “Add-KdsRootKey –EffectiveImmediately”
  3. Wait 10 hours or more (Enable it and leave it for a day)
  4. Test the KDS Root Key “Test-kdsrootkey –keyid <GUID from above>”
  5. Create a Security Group in AD which the computer accounts will be a member of to have access to retrieve the managed password. Important: Remember to reboot the computers once you have made them a member of a group.

  6. Add computer accounts as members to new group

    1. Reboot the server/s
  7. Create the gMSA “New-ADServiceAccount SQL2012Managed -DNSHostName -PrincipalsAllowedToRetrieveManagedPassword Allowed-SQL2012ManagedServiceAccount-Access -ServicePrincipalNames MSSQLSvc/SQL2012:1433,MSSQLSvc/”

  8. Success now you can start using the Managed Service Account for other installations.
  9. Open “Active Directory Administrative Center” to confirm Managed Service account creation


Step 2: Add the new service account to the required machines


Once you have created the Managed Service Account you need to assign it to all the required machines.

  1. Open Windows Powershell on the Server in my exsample I’ll open it on the SQL2012 Server that I’m going to use.
  2. Run the following command “Install-ADServiceAccount SQL2012Managed”

  3. To Confirm the account try to change a service to run under the newly created account

  4. Please see my next blog post on how to install SQL 2012 using managed service Accounts.

Cisco vs Huawei essential command mapping


ping ping
traceroute tracert
show display
show interfaces display interface
Show ip route display routing-table
Show ip interface Display ip interface
Show version Display version
Show ip bgp Display bgp routing-table
Show clock Display clock
Show port Display port-mapping
Show flash dir flash: (on user view mode)
Show logging Display logbuffer
Show snmp Display snmp-agent statistics
Show frame-relay pvc Display fr pvc-info
Show users Display users
Show terminal length screen-length disable

undo screen-length disable

enable Super
disable Super 0 (number is privilege level from 0 to 3, where 3 is default and equivalent to “enable” on Cisco)
Conf t System-view
exit quit
end return
Show policy-map interface Display qos policy interface
send send (on user view mode)
write terminal (sh run) display current-configuration
Sh startup Display saved-configuration
[no equivalent: shows the files used for startup] Display startup
Write erase Reset saved-configuration
Write mem (or wr or copy run start) save
clear counters reset (on user view mode)

Reset counters interface

? ?
telnet telnet
Enable secret (conf mode) Super pass cipher (system mode)
Term mon term debu
clock clock
no undo
debug / no debug debugging / undo debugging
copy running-config Save safely
terminal monitor terminal monitor
terminal length screen-length disable

undo screen-length disable

terminal no monitor undo terminal monitor
clear counters reset counters interface
clear interface reset counters interface
clear crypto ipsec sa

ike sa

clear access-list counters reset acl counter all
reload reboot
shutdown shutdown
boot boot bootrom
Aaa hwtacacs scheme
terminal no monitor undo terminal monitor
tacacs-server hwtacacs scheme (in conf command)
snmp-server tftp-server (in conf command)
router bgp bgp
Router rip rip
ip tacacs hwtacacs nas-ip (this command doesn’t exist !!!)
mtu Mtu (this command doesn’t exist !!!)
clear ip cef reset ip fast-forwarding
clear ip route * reset ip routing-table statistics protocol all
Clear ip bgp Reset bgp all
Show tech display diagnostic-information
Sh ip nat translation Display nat session
Show Controller display controller (but not relevant for non-modular chassis)
show dsl int atm 0 display dsl status interface Atm 2/0
sho atm pvc Display atm pvc-info
debug pvc nego Debug atm all (very dangerous – might crash router)
sho crypto isakmp sa Display ike sa
sho crypto isakmp key Display ike peer
sho crypto isakmp police Display ike proposal