In various customer discussions, it emerged that a single Azure Stack Development Kit (ASDK) did not correspond to the desired test scenarios. Especially since new ASDK versions should be deployed at regular intervals due to updates (monthly).
This customer scenario is exclusively an ASDK system, which is located in the customer’s internal network. However, there is certainly also a possibility to set up the system in such a way that it can be used by Managed Service Providers.
This gave us the idea to get more involved with the network configuration of the ASDK and, if possible, to make changes to it. Because if one speaks of a parallel operation of ASDKs, then one also talks about Tenant VPN access. The review of various blog posts on the net did not lead to the desired customer request.
Customer wishes were defined in the following form:
- several ASDKs in the same network
- Different configurations of the ASDKs
- Connected and Disconnected Mode
- with and without App Services
- with Kubernetes
- with and without AD FS and AAD
- Access from the customer’s local network with various Clients
With Powershell, we were able to adapt the Config XML of the ASDK to the desired customer scenarios. It is important to know that an ASDK has 62 IP addresses available, from which 31 IP addresses are already subtracted by the pure installation. Each additional resource provider installation requires IP addresses from this pool. There’s not much left in the end. With the well known subnetting you can get the desired result here.
In the next step, additional parameter values are added to the InstallPOC. ps1 script in the front section of the parameters. These serve to adapt the region names of the respective ASDKs. E. g. from “local”; to “hamburg”; or “RZ1”. The decision lies in the customer configuration in which the ASDks are added.
Since the ASDK has now adapted the RegionName, the custom DomainSuffix must also be specified if a Post Deploymennt is used for the installation of App Services (Script Matt McSpirit). It is the same name as the RegionName of the ASDK.
Since the network IP address range of the ASDK has been adapted, it must also be adapted either in the firewall, or the router where the various ASDKs are located. Just like setting up or configuring a DNS delegation.
The last hurdle is importing the ASDK certificates to all clients interacting with the systems.
The way to this overall configuration was not an easy one, but the time invested was worth it. This makes it possible to provide customers with differently configured systems for a Proof-of-Concept (PoC). The total running time of the PoC may also be reduced in the positive decision towards the Azure Stack Integrated System.
Questions, suggestions and wishes are very welcome.