Cloud Connector Edition and HTTP Proxy issue.

Hi all.

I recently came across an CCE problem for the first time, and hopefully this info can help others that may end up in the same situation.

Some customers are required, for compliance reasons, to run the Cloud connector behind a HTTP proxy. This is well documented in the Design and Planning whitepapers – so far so good.

The customer i worked with had all this in place. But when one CCE in HA went into “error” state in the portal they proceeded to do uninstall and install process – but then ran into problems.

After building the first server (AD) the script failed in the attempt to contact the servers via the Management Hyper-V vSwitch – connectivity was ok the hosts could ping the VM (with firewall disabled) but still the script failed with this error.

Wait-MtMachineOn : Can’t connect to machine 192.168.213.2 after waiting 600 seconds. At C:Program FilesWindowsPowerShellModulesCloudConnectorInternalMtAddc.ps1:329 char:9+ Wait-MtMachineOn $machineIPAddress $vmAdminCredential -WaitOffFirstly $t …+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Wait-MtMachineOn

This error points to connectivity issues. We thought we had that covered

Theese are my Troubleshooting checklists with CCE connectivity issues. 

  1. VLANS: Confirm that no VLAN’s have been configured on the Host machines 
  2. Virtual Switches: Confirm that the Virtual Switches configured on in Hyper-VHost appliance have the identical names as defined in the Cloud Connector Configuration File 
  3. Management Switch IP: This is set by CCE script, but could be changed by someone. Confirm that it’s assigned an IP address in management switch subnet range as defined in the Cloud Connector Configuration file. 
  4. IP address of the Host network adapter bound to the Cloud Connector SfB Corpnet Switch must have an IP address assigned to it in the same subnet range as the Corpnet subnet defined in the Cloud Connector INI file. This IP address can be configured as an alternate IP address if the you have requirement to have a different IP assigned on this adapter for managing the host computer. 
  5. Proxy Exclusions: If you are using a proxy server for Host appliance, confirm if you have made the appropriate proxy exclusions in WinHTTP for the CCE Management and Corpnet subnets as defined in the Cloud Connector INI file. 
  6. If a proxy server is required on the host machine, then you should configure a proxy exclusion for the Management and Corpnet subnets defined in Cloud Connector INI in the proxy bypass list. Otherwise host to VM connectivity will fail and prevent the deployment of Cloud Connector Edition. To bypass the proxy, specify WinHTTP Proxy settings set with your proxy server and a Bypass-list including the “192.168.213.*” network used by your Cloud Connector Managements services and the Skype for Business Corpnet subnet as defined in your CloudConnector.ini file. Otherwise, management connectivity will fail and prevent the deployment and auto recovery of Cloud Connector. The following is a sample winhttp configuration command: netsh winhttp set proxy “10.10.10.175:8080″ bypass-list=”*.local;1.*;172.20.*;192.168.218.*'<local>”. https://technet.microsoft.com/en-us/library/mt605227.aspx#Anchor_2 
  7. To ensure Internet downloads work, make Proxy settings per-machine rather than by user. Otherwise Cloud Connector downloads will fail. This can be done either with direct registry change, HKLMPoliciesMicrosoftWindowsCurrentVersionInternet ## Settings: ProxySettingsPerUser with Value of 0 (disabled), or Group Policy Computer>Administrative Templates>Windows Components> Internet Explorer: Make Proxy settings per-machine (rather than per user). https://technet.microsoft.com/EN-US/library/mt605227.aspx 
  8. Internal CCE Domain and SIP Domain are defined the same: https://support.microsoft.com/en-ph/help/3214408/-can-t-connect-to-machine-ip-address-after-waiting-600-seconds-error-a
  9. Invalid IP Addresses: Check if the switches on the CCE AD VM have Automatic Private IP Address (APIPA) of 169.x. Connect to the Host Appliance and open Hyper-V Manager from Control Panel > Administrative Tools Select the CCE VM (name will start with CCE Build #) Click on Networking Tab in the bottom pane and view the Networking Connection IP’s 

If the IP addresses are 169.x addresses, this is because the Convert-CcIsoToVhdx failed on Windows Updates because base VM couldn’t connect to Window Update Service to run updates. When this happens, the process errors out with a warning and information on how to connect to the machine to run updates and once that’s done, re-run the Convert-CcIsoToVhdx with -GeneralizeOnly parameter to sysprep and generalize the Base VM machine, copy the VHDX to “Site DirectoryBitsVHDSFBServer.vhdx”. When sysprep is not performed, the Unattend.XML answer file containing information to setup machine obtained from CloudConnector.ini file will not be used as the initial startup asking the questions will not be run. To resolve this, the customer should re-run convert cmdlet in Administrative PowerShell on the CCE Appliance as follows:

  1. Convert-CcIsoToVhdx -IsoFilePath <Windows ISO File Path, including file name> -PauseBeforeUpdate 
  2. When the script prompts that updates are ready to be run, connect to the Base VM using credentials provided in the instructions provided in the PowerShell output 
  3. Make any necessary adjustments to allow the computer to connect to Windows Update Service
  4. Complete all Windows Updates and restart the VM 
  5. When updates are completed, answer prompt in PowerShell output to continue the process 

We Checked all parts of the above 2 lists

But still same error. !?

Then we saw this in the NETMON trace:

TCPPayload: SourcePort = 80, DestinationPort = 52127

– Http: Response, HTTP/1.1, Status: Bad request, URL: http://192.168.213.2:5985/wsman

ProtocolVersion: HTTP/1.1

StatusCode: 400, Bad request

Reason: Bad Request

And although we had a mental checkmark on the Proxy part a clever colleague suggested to clear the Proxy Cache with this command:

“netsh winhttp reset proxy” on the HOST

And Hey Presto – after this was done install-ccappliance script went thorugh and the CCE came back online

Hope this will be usefull to someone 🙂

Happy SKYPE’ing.

Leave a Reply

Your email address will not be published. Required fields are marked *