09 Nov

Konube Integrator on Windows Azure Pack – Part 2 The issue and a deeper look

In this blog post I take a deeper look into the konube integrator because we expected some issues in our proof of concept environment. From my point of view there are some nice information to know for troubleshooting.

Let me shortly explain our issue:

Creating a connection, add this to a plan and let the user login and use the plan was working as expected. But always on creating a VM in Azure through the Konube connector fails with an „Internal server error“.
After some troubleshooting by ourself and also from the Schakra guys (Many thanks again!) the main issue was on using a proxy server for connection to the internet. The Ressource Provider wasn’t configured to use the proxy settings which are deployed in a group policy.
Konube runs in a usercontext, so the application pool needs to be configured to use the proxy setting and a domain user to get the group policy. This will be realised intwo steps, the web.config file of the application and using a domain account for the app pool. We need to extend the web.config file in this case:

    <defaultProxy enabled="true">
      <proxy usesystemdefault="true" />

Restarting the Aplication Pool and after that we are able to deploy a VM in Azure through our Azure Pack environment.

But lets take a look at some nice informations to troubleshoot the issue:


Konube is logging mainly into the EventViewer and uses the MgmtSvc-AdminSite and the TenantSite log


Konube has another log which you can find in the user profile of the service. Normally it is located in: c:\users\MgmtSvc-HybridCloud\AppData\Local\Konube



During our testing and troubleshooting we take a look at the databases of WAP and Konube. As I wrote before, Konube is registered as a Ressource provider in WAP. Because of the distributed WAP environment we play a liitle bit with the service enpoints and forwarder links in the database.

A registered Resource Provider is stored in the WAP Database in MgmtSvc-Store Part. 12


There are some more fields and we’re playing a little bit changing the TenantForwardingAddress. Please note that this is not supported in a production environment !


The next thing is that Konube creates IIS Websites and Application Pools on both, Admin and tenant site.


As we expected in the error i explained in Part 1 during the installation the AppPool must be configured with LoadUserProfile = true. This is also the point we configured the domain user to start the app pool – otherwise it will start with default app pool rights and never get our proxy settings.


I hope these details will help you a little bit if you are trying to find out what’s going on using Konube.