Ahoy there! This is my personal blog which I use as my memory extension and a medium to share stuff that could be useful to others.

For whatever reason, Microsoft stopped enabling the useful “Telnet Client” by default in its Operating Systems since Windows Server 2008 R2. So, on such OSes, the Telnet Client has to be enabled as a “Feature”.

After my first brush with Windows Server 2012, I realized that I must have shortcuts and commands handy to prevent the UI overhaul from impacting my efficiency.

So, here’s a handy command to install the Telnet client (run from the MS-DOS command prompt):

pkgmgr /iu:"TelnetClient"
VN:F [1.9.22_1171]
Rating: +9 (from 15 votes)

Earlier today, an application owner wanted his Windows Server 2003 SP2 VM restarted. So, I opened a Remote Desktop Connection (RDC) session to the VM and restarted it. After the VM started, I received the following exception when I tried to open an RDC session to the VM:

 

Win2003_RDC

Since I could no longer login via an RDC, I used the VMware vCenter to open a Console session to the VM and did the following:

  • Checked if Remote connections were enabled (had to be enabled as I logged in earlier to restart the VM). This feature was enabled. So, (1) in the above exception message was ruled out.
  • Checked Network Level Authentication (NLA). It was not supported. So, (2) in the above exception message was ruled out.
  • I could telnet from my laptop to port 3389 on the VM. So, (3) in the above exception message was ruled out.
  • Finally, I just restarted the VM again and I was surprised to find that I could then open an RDC session to the VM.

So, restarting the Windows Server 2003 SP2 VM via the console fixed the problem. I later searched the www and observed that many users experienced the same problem and the “console operation” was used to fix the problem.

I haven’t found the root cause yet (not happy), but don’t have the time to look into it now …

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

UCS CSR

While configuring certificates in UCSM 2.1(1f), I observed that the UCSM does not permit you to create a Certificate Signing Request (CSR) for certificates with more than one Subject Alternative Name (SAN).

However, you can create a certificate with 1 SAN as shown in the image below. The certificate’s SAN is requested using the DNS field (cybergav.com) and the CN is requested using the Subject field (cybergav.in).

 

UCS_CSR

If UCSM permitted users to create CSRs outside UCSM and just use the private key and certificate, then there would not have been any constraint on the certificates used. On the other hand, the current setup enhances security (private key generated and stored only in UCSM) and facilitates certificate configuration for cert newbies.

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

UCS MAC Nomenclature

Given below is a nomenclature for Cisco UCS MAC Addresses:

 

CiscoUCS_MAC_Nomenclature

 

Example:

00:25:B5:02:0B:02 => The second MAC address (OP=02) in a MAC Pool in UCS Domain 2 (KL=02) for an ESXi Host (M=0) in Fabric B (N=B)

VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

UCS WWN Nomenclature

Given below is a nomenclature for Cisco UCS WWPNs and WWNNs:

 

CiscoUCS_WWxN_Nomenclature

 

Examples:

(1) 20:00:00:25:B5:01:0A:01  => The first WWPN (OP=01) in a WWPN pool in UCS Domain 1 (KL=01) which is used by an ESXi host (M=0) in Fabric A (N=A).

(2) 20:00:00:25:B5:03:2F:03  => The third WWNN (OP=03 and N=F) in a WWNN pool in UCS Domain 3 (KL=03) which is used by a Linux host (M=2).

VN:F [1.9.22_1171]
Rating: -1 (from 1 vote)
 Page 2 of 33 « 1  2  3  4  5 » ...  Last »