Installing VMware View Composer 4.6 throws the error: “Error 28014. Unable to close the firewall.”

Problem

You proceed to install VMware View Composer 4.6 by executing the installation binary VMware-viewcomposer-2.6.0-34155:

… but as the install process commences, you are prompted with the following error message:

Error 28014. Unable to close the firewall.

The installation does not proceeds and rolls back.

Solution

The reason why you are prompted with this error message is because you did not run the installation binary as an administrator.  Simply right click on the installation file, choose Run as administrator and the installation should proceed without any issues:

Does “orphaned” virtual machines show up when executing “vim-cmd vmsvc/getallvms”?

I was asked an interesting question a few weeks ago when I was a part of an vSphere infrastructure start up after a datacenter move.  What basically happened was that the virtual machines and hosts were not shutdown in proper order and we suspected that some virtual machines might have failed over to some hosts without us knowing.  Since we were tight on time with a small window, we proceeded to complete the physical move and then began bringing up the virtual machines.  There were quite a few challenges on the way and as we proceeded to start up the critical virtual machines via console commands, I was asked the following:

If I’m executing the command “vim-cmd vmsvc/getallvms”, does the list of virtual machines that the command return include any orphaned virtual machines?

I didn’t know the answer but being the person that I am, I was extremely curious about the answer so made a note in my book to test it out.  What I found out a week later during a test was that it actually doesn’t.  Here are the results of the test:

As shown in the screenshot above, I intentionally orphaned a virtual machine named: Win7EntSP1-32Bit

I proceeded to execute the command vim-cmd vmsvc/getallvms via an SSH session and can see that the orphaned virtual machine does not show up in the list:

~ # vim-cmd vmsvc/getallvms
Vmid          Name                                   File                                  Guest OS          Version   Annotation
112    Win7EntNSP1-64-Bit   [datastore1] Win7EntNSP1-64-Bit/Win7EntNSP1-64-Bit.vmx   windows7_64Guest        vmx-07
16     Contoso-vCenter          [datastore1] Contoso-vCenter/Contoso-vCenter.vmx                 windows7Server64Guest   vmx-07
32     Contoso-VCS              [datastore1] Contoso-VCS/Contoso-VCS.vmx                         windows7Server64Guest   vmx-07
48     Contoso-SQL              [datastore1] Contoso-SQL/Contoso-SQL.vmx                         windows7Server64Guest   vmx-07
64     Contoso-VTS              [datastore1] Contoso-VTS/Contoso-VTS.vmx                         windows7Server64Guest   vmx-07
96     Win7EntNSP1-32-Bit   [datastore1] Win7EntNSP1-32-Bit/Win7EntNSP1-32-Bit.vmx   windows7Guest           vmx-07
~ #

Now that I know orphaned virtual machines doesn’t show up via the vim-cmd vmsvc/getallvms command, I’m definitely going to look into seeing whether there’s a way to list it and will write another post when I figure it out.

MOC 2007 R1 or R2 client throws the error: “Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book. If the problem persists, contact your system administrator.”

Problem

You have OCS 2007 R1 deployed in your environment and began noticing MOC (Microsoft Office Communicator) clients display a notification:

… labeled:

Cannot Synchronize Address Book

… with the error message:

Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book. If the problem persists, contact your system administrator.

Solution

After verifying that I was able to:

1. Browse the https://poolFQDN/ URL without being issued a certificate warning
2. Download a .lsabs file from the URL https://poolFQDN/abs/int/handler
3. View the Invalid_AD_Phone_Numbers.txt from the URL https://poolFQDN/abs/int/handler/Invalid_AD_Phone_Numbers.txt

… I realized that I was informed of the internal Certificate Authority being upgraded.  Although the keys from the decommissioned CA were restored onto the new CA, I had a feeling that perhaps the MOC client was still trying to contact the old CA because the pool was still using a certificate issued from the old CA.

After reviewing the pool’s certificate attributes, I had a thought that perhaps the MOC client (through Internet Explorer’s engine) was trying to contact the decommissioned CA to retrieve the certificate revocation list.  I remember coming across an article a year ago that showed how to modify the registry to skip a CRL check so after a bit of searching, I managed to find the instructions.

Location: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

Key: CertificateRevocation

Type: REG_DWORD

Options: 1 (turn on) or 0 (turn off)

Note how the registry key’s value is 1 (turned on):

So I proceeded to turn it off:

Signing out and back in did not remove the notification but closing and re-launching the MOC client did: 

 

So what part of the certificate tipped me off?  Here are the details to the CRL Distribution Points field:

[1]CRL Distribution Point

     Distribution Point Name:

          Full Name:

               URL=ldap:///CN=Contoso%20Ltd,CN=CERT01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=internal?certificateRevocationList?base?objectClass=cRLDistributionPoint

               URL=http://cert01.Contoso.internal/CertEnroll/Contoso%20Ltd.crl

 

The server named cert01 no longer existed because the new certificate authority is now named cert02.  Hope this post helps anyone out there who may encounter the same problem as I did.

OCS 2007 R1 MOC client displays the error message: “Communicator could not retrieve calendar or Out of Office information from Exchange Web Services. Communicator will automatically continue to retry. If this problem persists, contact your system administrator.”

Problem

You have OCS 2007 R1 deployed in your environment and began noticing MOC (Microsoft Office Communicator) clients display a notification:

… labeled:

Exchange Connection Error

… with the error message:

Communicator could not retrieve calendar or Out of Office information from Exchange Web Services. Communicator will automatically continue to retry. If this problem persists, contact your system administrator.

Solution

While there are various reasons why you may see this message and the first item to check would be your Exchange Server 2007 or 2010’s EWS services, if you determine that the service is configured and in working order, check that your MOC R1 clients are fully up-to-date.  Microsoft has acknowledged that this can be caused by an earlier version of MOC and patching the client may solve this issue.  The patches can be found here:

MOC R1: http://support.microsoft.com/kb/2300255

More information about the root cause can be found in the KB articles listed above.

You notice the notification “Limited External Calling” displayed on your MOC client when setting up Avaya RCC integration with Lync Server 2010 while in coexistence with OCS 2007

Problem

You noticed that after you’ve configured your Avaya AES server in the Trusted application servers node in your Lync Server 2010 topology:

… you notice that legacy OCS 2007 MOC clients being having the notification: Limited External Calling with the message:

Some calls to and from people outside of your corporate network may not connect due to server connectivity problems. Try signing out and signing back in. If this problem continues, contact your system administrator with this information.

You log into the Front End Properties of the OCS 2007 pool:

… and notice that the settings for your Host Authorization tab are missing:

So you proceed and fill the AES server settings back in and perform a Front End Server validation on your OCS 2007 front-end server:

… and notice the following failures / errors thrown:

Failure
[0xC3FC200D] One or more errors were detected

Error: Multiple server roles (TrustedUnknownService,AuthorizedHost) are configured at the same address aes.contoso.local but they have different trust options.

You also notice that if you stop the Office Communications Server front-end service, you are no longer able to start it back up.  It is not until you remove the Host Authorization entries that you are able to start your OCS 2007 front-end server service. 

Reviewing the event logs in OCS 2007 administration tools show the following errors and warnings logged:

The server configuration validation mechanism detected some potential problems. The server might not behave as expected.

The server [aesdr.contoso.local] is configured as the next hop for the static route [aesdr.contoso.local] but it is not a known configured server. Check the 'Host Authorization' pane in MMC.

Error code is:0xC3E93C47 (SIPPROXY_E_BAD_SERVER_CONFIGURATION).
Cause: Check the previous entries in the event log for the failure reason.
Resolution:
Try restarting the server after resolving the failures listed in the previous event log entries.

Error: 0x0xC3E93C47 (SIPPROXY_E_BAD_SERVER_CONFIGURATION).

Cause: There are serious problems with the server configuration that prevented it from starting up.
Resolution:
Review the previous event log entries to identify failures. Alter the server configuration as required. If problems persist, contact product support.

ERRORS:
Two server roles at FQDN [aes.contoso.local] have different server version numbers. First server has GUID {2D42A164-43D3-462A-98D5-FB583A8573C7} and role 'Authorized Host' (version 0). Second server has GUID {D377357E-721A-5594-9107-F3EBD1A68BF5} and role 'Application Server' (version 5).
WARNINGS:
The server [aesdr.contoso.local] is configured as the next hop for the static route [aesdr.contoso.local] but it is not a known configured server. Check the 'Host Authorization' pane in MMC.
Cause: The configuration is invalid and the server might not behave as expected.
Resolution:
Review and correct the errors listed above, then restart the service. You also wish to review any warnings present.

Reviewing the application logs in the event logs show the following:

Event ID: 14518

The server configuration validation mechanism detected some potential problems. The server might not behave as expected.

1 warnings were detected:

The server [aesdr.contoso.local] is configured as the next hop for the static route [aesdr.contoso.loca] but it is not a known configured server. Check the 'Host Authorization' pane in MMC.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event ID: 14496

Failed to remove a server from the known servers table.

Server=[aes.contoso.local]. InstanceID={2D42A164-43D3-462A-98D5-FB583A8573C7}. Error=0xC3E93C4E (SIPPROXY_E_UNKNOWN_SERVER).

Cause: This may be due to a previous failure.

Resolution:

Check the previous event log entries for failures. Restart the server. If the problem persists, contact Product Support Services.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event ID: 12326

Failed starting the protocol stack. The service has to stop

Error code is:0xC3E93C47 (SIPPROXY_E_BAD_SERVER_CONFIGURATION).

Cause: Check the previous entries in the event log for the failure reason.

Resolution:

Try restarting the server after resolving the failures listed in the previous event log entries.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event ID: 14352

Unable to start the stack.

Error: 0x0xC3E93C47 (SIPPROXY_E_BAD_SERVER_CONFIGURATION).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp

Event ID: 14497

One or more configuration errors were detected at startup that cannot be mitigated.

Cause: There are serious problems with the server configuration that prevented it from starting up.

Resolution:

Review the previous event log entries to identify failures. Alter the server configuration as required. If problems persist, contact product support.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event ID: 14517

The server configuration validation mechanism detected some serious problems.

1 errors and 0 warnings were detected.

ERRORS:

Two server roles at FQDN [aes.contoso.local] have different server version numbers. First server has GUID {46F7B75D-1FB4-4388-B186-6E38E3211540} and role 'Authorized Host' (version 0). Second server has GUID {D377357E-721A-5594-9107-F3EBD1A68BF5} and role 'Application Server' (version 5).

WARNINGS:

No warnings

Cause: The configuration is invalid and the server might not behave as expected.

Resolution:

Review and correct the errors listed above, then restart the service. You also wish to review any warnings present.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Solution

This problem actually took me quite some time to figure out as I searched long and hard for the GUIDs referenced in the event logs but wasn’t able to find an exact match.  As I started running out of ideas, I figured I had nothing to lose by just opening up the objects in ADSIedit to see if something may catch my eye and as I browsed through the attributes of objects, I noticed the following:

The msRTCSIP-TrustedS… attribute avaya-bda-rcc is the logical name I used to created the Trusted Application Servers in the Lync Server 2010 topology builder.  Seeing how I had nothing else on my mind that I could try, I went ahead to remove that setting, published the Lync topology and long behold the OCS 2007 front-end server service began starting up.

I’m not exactly sure what the reason is but my guess is that the 2 objects somehow conflicted with each other and because I didn’t have time to further look into the problem, I just went ahead and left it as is until I have some spare cycles to figure this out.  For those who may be wondering why this isn’t a priority for me, it’s because we’re not going to be able to integrate Lync with the current AES server which is 2 versions behind the supported one.

I’ll update this post when the AES gets upgraded and the integration continues again.

Cisco releases UCS B Series Infrastructure Firmware 2.0

Cisco has just released the highly anticipated 2.0 firmware for the UCS B series infrastructure on their public download site.  I’m extremely excited to test it out next week!

Running a VMware Site Recovery Manager recovery plan errors out with the message: “Error: Reason: Could not open/create change tracking file.”

Problem

You notice that executing one of your recovery plan errors out at the Prepare Storage step with the message:

Error: Reason: Could not open/create change tracking file.

The logs will show that the step fails as follows:

6. Recover Low Priority Virtual Machines	Error: Reason: Could not open/create change tracking file.	00:29:04
6.1. Recover VM "someServer.domain.com"	Success: Host 'someServer.domain.com'	00:17:31
6.1.1. Change Network Settings	Success	00:07:31
6.1.2. Pre-Power On	Success	00:00:00
6.1.3. Power On	Success: Host 'someServer.domain.com'	00:00:06
6.1.4. Wait for OS Heartbeat	Success	00:09:52
6.1.5. Post Power On	Success	00:00:00
6.2. Recover VM "someServer.domain.com"	Success: Host 'someServer.domain.com'	00:12:30
6.2.1. Change Network Settings	Success	00:06:40
6.2.2. Pre-Power On	Success	00:00:00
6.2.3. Power On	Success: Host 'someServer.domain.com'	00:00:04
6.2.4. Wait for OS Heartbeat	Success	00:05:44
6.2.5. Post Power On	Success	00:00:00
6.3. Recover VM "someServer.domain.com"	Success: Host 'someServer.domain.com'	00:05:49
6.3.1. Change Network Settings	Success	00:03:21
6.3.2. Pre-Power On	Success	00:00:00
6.3.3. Power On	Success: Host 'someServer.domain.com'	00:00:04
6.3.4. Wait for OS Heartbeat	Success	00:02:04
6.3.5. Post Power On	Success	00:00:00
6.4. Recover VM "someServer.domain.com"	Error: Reason: Could not open/create change tracking file.	00:18:26
6.4.1. Change Network Settings	Error: Reason: Could not open/create change tracking file.	00:18:26

Solution

There are typically two reasons why SRM will fail with this error message during a test or actual recovery and that’s because:

1. The virtual machine SRM is trying to recovery has a snapshot
2. The virtual machine SRM is trying to recovery has a corrupted CTK file (Changed Block Tracking also known as CBT)

If the issue is related to #1, try deleting the snapshot and execute the test again.

**Note that the virtual machine in the screenshot above does not have any snapshots which is why the Delete All button is grayed out.

If you suspect that the issue is related to #2, check the problematic virtual machine’s folder where its files are stored and see if there’s a CTK file:

I won’t go into the details of what the CTK file but if you want to read more about it, have a look at the following VMware public KB:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020128

The easiest way to try and rectify this issue is to create a snapshot for the problematic virtual machine and then delete the snapshot.

This usually refreshes a CBT enabled virtual machine’s CTK file.  I haven’t experienced this problem many times but whenever I do, this appears to fix the problem pretty well.

Hope this post provides anyone who may be experiencing this issue a starting point on how to troubleshoot this error.