Sunday, December 14, 2014

Upgrading Nutanix blades from ESXi 5.1 to 5.5

I don’t usually perform upgrades of Nutanix blocks from 5.1 to 5.5 but I’ve noticed that whenever I do, I’ve always had to reference an email in my Outlook’s Draft folder with the notes and screenshots I’ve captured during a previous upgrade so just in case I needed to reference it in the future, I’m going to go ahead and get a post written on my blog.

The configuration I’ll be upgrading in this example consists of an older Nutanix 2000 series block with 2 blades and a newer Nutanix 7000 series block with one blade running ESXi 5.1.0 build 1065491:

image

image

image

This upgrade was performed a while ago so the version we’ll be upgrading to is VMware ESXi 5.5 build 1331820.

Step #1 – Download Upgrade Package

I find that one of the questions I get asked most from colleagues and clients are that they cannot find the the upgrade package by navigating through VMware’s download section.  The reason for this is usually because they are navigating to an update of version 5.5.0 with the path such as:

Home –> All Downloads –> VMware vSphere –> VMware ESXi 5.5.0 Update 1

The section above provides the following options:

  • ESXi 5.5 Update 1 Driver Rollup 2 (includes VMware Tools)
  • ESXi 5.5 Update 1 Driver Rollup 2 README
  • ESXi 5.5 Update 1 ISO image (includes VMware Tools)
  • ESXi 5.5 Update 1 Offline Bundle

imageimage

None of the above can actually be used to upgrade our blades from ESXi 5.1 to 5.5 because the ESXi 5.5 Update 1 Offline Bundle is only used for updating 5.5.0 to 5.5.0 U1.  Downloading the first package on the list would provide you with ISOs for installing ESXi 5.5U1 on a new blade.  As an example, here’s what the contents of the VMware-ESXi-5.5U1-Rollup_2ISO.iso contain:

image

image

The correct page that you’re looking for is to select the RTM version of 5.5.0 as such:

image

Here is where you will find the ESXi Offline Bundle:

image

The upgrade package should be in the form of a zip package that ends with -depot.zip:

image

image

Opening the zip package should show the following file and folders:

vib20 – Folder
vmv-ESXi-5.5.0-metadata.zip – File
index.xml – File
vendor-index.xml – File

image

Step #2 – Upload Upgrade Package to Datastore

With the upgrade package downloaded, proceed by uploading the package to a datastore accessible by all of the hosts:

imageimage

Step #3 – Connect to CVM to Execute Upgrade

With the upgrade package uploaded, proceed by SSH-ing to any one of the CVMs:

image

… then execute the following:

i in `hostips`;do echo $i && ssh root@$i "esxcli software vib install -d /vmfs/volumes/NutanixNFS/VMware-ESXi-5.5.0-1331820-depot.zip";done

Note that you will need to change the path to the upgrade package (highlighted in red) to reflect the environment you are working in.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

Note that if you receive the following error:

ssh: Could not resolve hostname hosttips: Name or service not known

image

It’s because you need to replace the characters for hostips with the symbol beside the 1 key:

for i in 'hostips';do echo $i && ssh root@$i "esxcli software vib install -d /vmfs/volumes/NutanixNFS/VMware-ESXi-5.5.0-1331820-depot.zip";done

--------------------------------------------------------------------------------------------------------------------------------------------------------------

The output of the upgrade should look something similar to the following:

image

image

The output from the SSH session should display the following for each successfully upgraded blade in the cluster:

Installation Result

Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.

Reboot Required: true

Step #4 (Optional) – Upgrading individual blades

If there is any issue with upgrading a specific blade in the cluster via the command ran in the CVM or if you would like to upgrade one blade to test, it is possible to simply SSH directly to the ESXi host and use the regular esxcli command to upgrade the host as such:

esxcli software vib install -d /vmfs/volumes/NutanixNFS/VMware-ESXi-5.5.0-1331820-depot.zip

image

imageimage

Step #5 – Apply Update Packages

With the hosts upgraded to the latest version, you can proceed with repeating the same process as Step #3 or #4 to apply Update packages downloaded from the appropriate section of the site:

image

Friday, December 12, 2014

Attempting to register a package from a script file (.RSP) on a Wyse Device Manager manager fails with: “Unable to connect to the HTTP Repository”

Problem

You need to move Package Manager Images from one WDM server to another by following the instructions found at this URL:

https://support.wyse.com/OA_HTML/csksxvm.jsp?nSetId=26518&nUsePub=NO&jttst0=6_23871,23871,-1,0,&jtfm0=&etfm1=&jfn=ZGAC0F217415CC7186A83C4B85C3E8044B1347842403EDE204F64AE27372AEDC74F923EF3C8412DD9F0B17F866C966EE089B&oas=hPgVmjwPoeUVu6hGtLpgiA

image

image

image

image

image

image

… but notice that you are unable to register the image because it fails with:

Unable to connect to the HTTP Repository

image

Proceeding to use the Test Connection feature for the Software Repository as such:

image

… fails with the error:

Name: HTTP Connection
Progress: Test Testing Complete
Status: Failed

image

Clicking on the Errors tab displays the following error:

[Error:Not Available] [WebDAV error:Failed to upload buffer. HTTP Response Code: 401Remote File Path: {A33AADB7-443F-4113-A478-D5A07E5518E0}.tmp Error Code: 401]

image

Solution

While there could be various reasons why this error would be thrown, one of the users is if the rapport service account password has expired and requires a new password to be set.  To determine this, launch the Computer Management console on the Wyse Device Manager server and navigate to the Local Users and Groups –> Users node, then open the rapport service account properties:

image

Notice that the User must change password at next login is checked which means the password has expired and must be changed.  Proceed by unchecking the checkbox and check the Password never expires checkbox:

image

Run Test Connection again for the Software Repository to ensure that the test completes successfully:

image

You should now be able to register the image.

Tuesday, December 9, 2014

Notes when working with Microsoft CA (Certificate Authority) services

I recently had to work with a Microsoft support engineer to troubleshoot an Active Directory Certificate Services issue and managed to write down a few commands he used during the troubleshooting process and thought I’d write a blog post so I can refer to them in the future since I’m bound to forget.

Command to collect CA information CRL:

Before starting the troubleshooting, the engineer ran the following commands to collect base information.

The following certutil command lists the Enterprise Root or Subordinate CAs found in Active Directory:

C:\>certutil

Entry 0:

Name: `test'

Organizational Unit: `'

Organization: `'

Locality: `'

State: `'

Country/region: `'

Config: `conspschsrv.contoso\test'

Exchange Certificate: `'

Signature Certificate: `'

Description: `'

Server: `conspschsrv.contoso'

Authority: `test'

Sanitized Name: `test'

Short Name: `test'

Sanitized Short Name: `test'

Flags: `1'

Web Enrollment Servers: `'

Entry 1:

Name: `CONTOSO ROOT CA'

Organizational Unit: `'

Organization: `'

Locality: `'

State: `'

Country/region: `'

Config: `conCERTSRV.contoso\Contoso ROOT CA'

Exchange Certificate: `'

Signature Certificate: `'

Description: `'

Server: `conCERTSRV.contoso'

Authority: `CONTOSO ROOT CA'

Sanitized Name: `CONTOSO ROOT CA'

Short Name: `CONTOSO ROOT CA'

Sanitized Short Name: `CONTOSO ROOT CA'

Flags: `1'

Web Enrollment Servers: `'

Entry 2: (Local)

Name: `CONTOSO-Sub-CA'

Organizational Unit: `'

Organization: `'

Locality: `'

State: `'

Country/region: `'

Config: `conSCASRV01.contoso\CONTOSO-Sub-CA'

Exchange Certificate: `'

Signature Certificate: `conSCASRV01.contoso_CONTOSO-Sub-CA.crt'

Description: `'

Server: `conSCASRV01.contoso'

Authority: `CONTOSO-Sub-CA'

Sanitized Name: `CONTOSO-Sub-CA'

Short Name: `CONTOSO-Sub-CA'

Sanitized Short Name: `CONTOSO-Sub-CA'

Flags: `13'

Web Enrollment Servers: `'

CertUtil: -dump command completed successfully.

Note that the above output shows that there are currently 3 Enterprise CAs that is found in Active Directory.

-------------------------------------------------------------------------------------------------------------------------------------------------------

The net config rdr command shows how the redirector or workstation is currently configured on your computer.  The following output is from a command prompt on the Enterprise Subordinate CA:

C:\>net config rdr

Computer name \\conSCASRV01

Full Computer name conSCASRV01.contoso

User name TLuk

Workstation active on

NetBT_Tcpip_{4C336E8C-128B-4B8F-99EC-BFD21F1B9E6D} (005056A10F07)

Software version Windows Server 2012 Standard

Workstation domain con-CONTOSO

Workstation Domain DNS Name contoso

Logon domain con-CONTOSO

COM Open Timeout (sec) 0

COM Send Count (byte) 16

COM Send Timeout (msec) 250

The command completed successfully.

-------------------------------------------------------------------------------------------------------------------------------------------------------

The following nltest /dclist:contoso command lists the domain controllers found in Active Directory:

C:\>nltest /dclist:contoso

Get list of DCs in domain 'contoso' from '\\DC2.contoso'.

DC2.contoso [DS] Site: Default-First-Site-Name

DC3.contoso [DS] Site: Default-First-Site-Name

DC1.contoso [PDC] [DS] Site: Default-First-Site-Name

The command completed successfully

C:\>

-------------------------------------------------------------------------------------------------------------------------------------------------------

Command to dump certificate information CRL:

The support engineer suspected that there was something wrong with the published CRL so the following command was executed to check the start and end validity date of the file (I’ve highlighted this information in red:

C:\>certutil -dump Contoso-Root-CA.crl
X509 Certificate Revocation List:
Version: 2
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.10 RSASSA-PSS
    Algorithm Parameters:
    30 00
Issuer:
    CN=Contoso-Root-CA
  Name Hash(sha1): b8e12ef9872c9e93d65fbd132a2402fa4b0d0dde
  Name Hash(md5): 9fe720a14c52866f8ffb9819659eb114

ThisUpdate: 11/30/2013 3:12 PM
NextUpdate: 11/30/2014 3:32 AM
CRL Entries: 0
CRL Extensions: 5
    2.5.29.35: Flags = 0, Length = 18
    Authority Key Identifier
        KeyID=b2 be 9e 66 df 55 a8 33 b7 72 00 77 a5 2a e5 19 68 6a d9 90

    1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3
    CA Version
        V0.0

    2.5.29.20: Flags = 0, Length = 3
    CRL Number
        CRL Number=02

    1.3.6.1.4.1.311.21.4: Flags = 0, Length = f
    Next CRL Publish
        Saturday, November 29, 2014 3:22:16 PM

    1.3.6.1.4.1.311.21.14: Flags = 0, Length = cb
    Published CRL Locations
        [1]Locations
             Distribution Point Name:
                  Full Name:
                       URL=ldap:///CN=Contoso-Root-CA,CN=BHLRCASRV01,CN=CDP,CN=Pub
lic Key Services,CN=Services,CN=Configuration,DC=contoso,DC=domain,DC=bm?certificateR
evocationList?base?objectClass=cRLDistributionPoint (ldap:///CN=Contoso-Root-CA,CN
=BHLRCASRV01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso
,DC=domain,DC=bm?certificateRevocationList?base?objectClass=cRLDistributionPoin
t)

Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.10 RSASSA-PSS
    Algorithm Parameters:
    30 00
Signature: UnusedBits=0
    0000  cb e3 84 68 86 fc af 5c  83 6a 1d 5a ef f8 74 11
    0010  ae d8 33 c3 0f cf 99 f9  24 d7 47 d6 90 09 24 a9
    0020  c9 06 c0 4b 3e 91 bc 96  5b cc ba 87 d5 72 68 1c
    0030  60 a7 fc a3 a1 6c 00 b5  5a 76 23 a4 29 89 fe bf
    0040  0d 9c 0f 74 57 15 9a 05  39 0f a3 05 39 a5 08 33
    0050  c5 b2 31 3d 16 b2 69 dd  16 62 09 db d3 d0 37 db
    0060  65 77 bc 4e 06 84 40 0d  e9 35 7c 03 c3 a0 36 4a
    0070  57 6c c8 3f 9b 07 b2 16  f1 16 43 46 de 27 96 7e
    0080  5b 32 e9 6d 24 eb 58 8d  1f 0f e5 ea 41 e4 64 e7
    0090  66 8d 46 f0 0c 4c 3c ab  13 12 da 3a f3 ac 2f cb
    00a0  37 80 9f a5 1d 6d bf db  cc 2e 48 ae 00 b1 56 83
    00b0  e3 0e 02 9a 29 e4 55 58  22 4b a1 ba 0f 1f bd 14
    00c0  3e 0b 37 dc af b3 35 33  48 ba 1c bc b5 6f 22 47
    00d0  49 99 d5 ac e5 68 fd 4f  30 7e ba 63 25 d9 6f 3e
    00e0  0c 3e 26 84 0b 29 6c d4  76 7c 44 8f 2b 71 a0 e9
    00f0  80 71 e0 2f 11 ec e7 02  62 3e 60 05 3a 27 bb 3d
CRL Hash(md5): 40 65 78 62 9a 86 fa 9f fb 77 57 43 e1 bc 23 66
CRL Hash(sha1): 26 92 02 b6 8e ab 26 41 b3 17 18 76 3f c5 41 45 a6 75 54 5e
CRL Hash(sha256): 6da08e776a532e6b92d1ebe7ffd477606f37b7d3659361661c50b8be9919cc
c3
Signature Hash: 438535ec7850261962dff88f6b73c487ae45633c
CertUtil: -dump command completed successfully.

The CRL file this command references can be found in the following directory:

C:\Windows\System32\certsrv\CertEnroll

Note that if this is too short, the period can be extended by launching the Certificate Authority administration console:

image

… right clicking on the Revoked Certificates and selecting properties:

image

… then changing the CRL publication interval to the desired duration:

image

-------------------------------------------------------------------------------------------------------------------------------------------------------

Command to publish certificate to LDAP

Updating the CRL file for http access is simply copying the CRL file from the Root CA’s C:\Windows\System32\certsrv\CertEnroll folder to the same folder on the Subordinate CA but to update the one published through LDAP, the command certuitl -dspublish <Your-Root-CA>.crl <YourSubOrdinateCAServerName is ran on the subordinate CA:

C:\>certutil -dspublish Contoso-Root-CA.crl CONSCASRV01
ldap:///CN=Contoso-Root-CA,CN=BHLSCASRV01,CN=CDP,CN=Public Key Services,CN=Service
s,CN=Configuration,DC=contoso,DC=bhl,DC=bm?certificateRevocationList

Base CRL added to DS store.

CertUtil: -dsPublish command completed successfully.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Verifying published CRL paths:

To verify the published CRL paths, simply export the subordinate CA’s certificate without the private key to a DER format file:

image

Then launch the URL Retrieval Tool by executing certuilt -url <exportedCA>.cer and use the Retrieve button with CRLs (from CDP) selected to verify the accessibility and validity of the files:

image

-------------------------------------------------------------------------------------------------------------------------------------------------------

Determining which certificate the current CA is using:

If the certificate for the CA has been renewed several times, you may end up seeing a list similar to the following:

image

While most of us would probably just look for the certificate with the latest expiry date, another way to do it is to open up the Registry Editor and navigate to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<YourCAName>

The CACertHash key can be used to identify which certificate is currently in use:

image

… by comparing it to the certificate’s Thumbprint as such:

image

Tuesday, December 2, 2014

Deploying Office Web Apps for Lync 2013 internal and external access

I’ve been asked on several occasions over the last 2 years since I’ve written the following post demonstrating how to deploy an Office Web Apps Server:

Deploying Office Web Apps Server on Windows Server 2012 for Lync Server 2013 Enterprise or Standard Pool
http://terenceluk.blogspot.com/2013/01/deploying-office-web-apps-server-on.html

… as to why I never included instructions on how to publish this service externally because the configuration only allows for internal access. I’m not sure why but writing this follow up post seems to have consistently slipped my mind over the past 2 years so without further delay, this post will demonstrate how to configure the Office Web Apps server to serve PowerPoint presentations for both internal and external Lync conference meetings.

I won’t go into the details for the Office Web Apps server install because my previous post demonstrate this so I’ll begin by explaining the URLs I have chosen for internal and external:

Internal URL: wac.domain.com
External URL: wac.domain.com

As shown above, I am using the same URL for both internal and external access.  This isn’t a requirement but I chose to do so because the public certificate we’ll be using is actually shared with the other Lync services and it only includes the public URL for the Office Web Apps server service.  You could easily use the FQDN of the Office Web Apps server if you put that as a SAN entry into the certificate.  It is also important to note that there is no way for you to assign a different certificate to the external URL and internal URL as you are forced to use the same certificate which I hope would change in future versions to give us a bit more flexibility when configuring the farm.

Begin by creating the the Office Web Apps Server object in the Lync Server 2013 Topology Builder and use the external URL as the FQDN:

image

The following is the certificate the the Office Web Apps server will be using for both the external and internal URL:

image

Make a note of the friendly name of the certificate as we’ll need it when we create the Office Web Apps farm:

image

Continue by logging on the Office Web Apps server and launching the Windows PowerShell console and use the following cmdlet to create a new Office Web Apps Farm:

New-OfficeWebAppsFarm -InternalUrl “https://wac.FQDN -ExternalUrl “https://wac.FQDN-CertificateName "<Certificate Friendly Name>"

For the purpose of this example, we’ll be using the following cmdlet:

New-OfficeWebAppsFarm -InternalUrl “https://wac.domain.bm” -ExternalUrl “https://wac.domain.bm” -CertificateName "sip.domain.bm"

image

With the Office Web Apps farm configured, the last items to complete are as follows:

  1. Create an internal DNS record pointing to wac.domain.bm to the internal IP of the Office Web Apps server
  2. Allocate a public IP
  3. Create the external DNS record wac.domain.bm that maps to the public IP allocated in step #2
  4. Create a NAT rule on the firewall that passes TCP 443 to the internal IP of the Office Web Apps Server
  5. Test sharing PowerPoint presentations for external with external, external with internal, internal with internal

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Please be advised that this is only one of the ways to configure Office Web Apps for a Lync 2013 deployment and depending on the environment, I may use different URLs for internal and external access while adding an external entry on the certificate.

Saturday, November 29, 2014

Lync Server 2013’s Deploy Monitoring Reports wizard throws the error: Cannot grant ReportsReadOnly Role to user “domain\accountName”. For details, see the following error message: Exception calling “Create” with “0” argument(s): “Create failed for Login ‘domain\accountname’. “

Problem

You’re in the process of deploying Monitoring Reports for Lync Server 2013:

image

… and proceed through the deployment but receive the following error:

Cannot grant ReportsReadOnly Role to user “domain\accountName”. For details, see the following error message:

Exception calling “Create” with “0” argument(s): “Create failed for Login ‘domain\accountname’. “

image

Solution

When entering the name for the User name (domain\user name): field, ensure that you use all capitals for the domain name as such:

CONTOSO\<username>

… because it needs to conform with the SQL Server standard as shown here:

image

Using small letters such as:

contoso\<username> will throw the error shown above.

image

Once this format is used, the deployment should complete without any errors:

image