If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
Reviewing the deployment scenario
In the previous series Deployment Windows Azure Pack we looked at how to perform an express deployment of Windows Azure Pack. As Figure 1 below shows, an express deployment involves installing all required components of Windows Azure Pack on a single server in an existing System Center 2012 R2 Virtual Machine Manager environment. The test environment used for the previous series was a virtual environment running on a single Hyper-V host as shown.
Figure 1: An express deployment of Windows Azure Pack.
Performing an express deployment of Windows Azure Pack involves installing all the required components which includes:
- Management Portal for Administrators
- Management Portal for Tenants
- Admin authentication site
- Tenant authentication site
- Admin API
- Tenant API
- Tenant public API
- SQL management database
At the completion of our express deployment in the last article of the previous series, we were able to successfully log on to the Management Portal for Administrators as shown in Figure 2 below, and this seemed to validate the deployment process as successful.
Figure 2: The management portal for administrators.
Does this mean we can start using Windows Azure Pack to begin provisioning new virtual machine clouds and web sites? Unfortunately not as we can quickly observe by selecting the VM Clouds item on the left side of the Management Portal:
Figure 3: Windows Azure Pack isn’t ready yet to provision new virtual machine clouds.
Clicking +New on the command bar at the bottom of the Management Portal confirms this since no option is displayed for creating new virtual machine clouds:
Figure 4: Confirmation that Windows Azure Pack isn’t ready yet to provision new virtual machine clouds.
Clearly something is missing here, and what’s missing is some additional configuration of Windows Azure Pack to enable the optional resource provider for virtual machine clouds. But before we look at how to perform such additional configuration, we should make sure our express deployment of Windows Azure Pack is working properly. To do this, we’re going to run the Best Practices Analyzer (BPA) for Windows Azure Pack.
Preparing to use the BPA
Before we can use the BPA for Windows Azure Pack, we need to make sure it’s installed. Running the Web Platform Installer shows that the BPA has already been installed as part of our express deployment of Windows Azure Pack:
Figure 5: Step 1 of preparing to use the BPA.
To be able to run the BPA, you need to install the Microsoft Baseline Configuration Analyzer 2.0 (MBCA 2.0). This can be downloaded from the Microsoft Download Center as shown here:
Figure 6: Step 2 of preparing to use the BPA.
Be sure to download the correct architecture version of the MBCA:
Figure 7: Step 3 of preparing to use the BPA.
Once you’ve downloaded MBCA_Setup64_Win8.msi you can run it to install the MBCA on the single server WAP01 used for our express deployment of Windows Azure Pack. But before you do this you need to make sure the .NEt Framework 2.0 is installed on WAP01. You can do this by adding the .NET Framework 3.5 feature using the Add Roles and Features Wizard of Server Manager:
Figure 8: Step 4 of preparing to use the BPA.
You can now run MBCA_Setup64_Win8.msi to install the MBCA:
Figure 9: Step 5 of preparing to use the BPA.
You’re now ready to run the BPA.
Running the BPA
Open the File Explorer and browse to the C:\Program Files\Microsoft Baseline Configuration Analyzer 2 folder and double-click on MBCA.exe to launch the MBCA:
Figure 10: Step 1 of running the BPA.
The home page of the MBCA should look like this:
Figure 11: Step 2 of running the BPA.
Click the down arrow in the listbox and select the Windows Azure Pack option as shown here:
Figure 12: Step 3 of running the BPA.
Now click Start Scan in the above figure. A progress bar should be displayed when the BPA scan is underway:
Figure 13: Step 4 of running the BPA.
When the BPA scan of your express deployment of Windows Azure Pack has completed, the results should look something like this:
Figure 14: Step 5 of running the BPA.
The scan results in the figure above show a number of warning items (37 in total) so let’s examine next what these indicate.
Examining the BPA results
The previous figure above showed a number of different warning items that begin with the words “Certificate type for…” What do these warnings mean? Let’s look at one of them in detail:
Figure 15: Details of a “Certificate type for AdminAPI” warning item.
The above details for the “Certificate type for AdminAPI” warning item are telling us that we have installed a self-signed SSL certificate on our express deployment of Windows Azure Pack. As a result, tenants might see an untrusted SSL certificate warning when they try to open this site, which might confuse them and cause them to think they are going to a malicious site. Well, we already know about this, so let’s move on and examine some other warning items.
Figure 16: Compatibility warnings from running the BPA.
The figure above shows a bunch of warning items that begin with the words “Compatibility of the installed features…” What do these warnings mean? Let’s examine one of them:
Figure 17: Details of a “Compatibility of the installed features” warning item.
The above details for the “Compatibility of the installed features” warning item are telling us that the AdminAPI and AuthSite components, which are both required components of Windows Azure Pack, are installed on the same machine (WAP01) and that this is generally not a good idea for security reasons. Specifically, in a real-world deployment of Windows Azure Pack you want the AdminAPI component to be accessible from the Internet while the AuthSite component is safely protected behind a firewall. But we’re only doing a proof of concept (PoC) express deployment of Windows Azure Pack here, so this and similar warnings can safely be ignored.
The next figure shows some “Feature access…” and “SSL validation status…” warning items:
Figure 18: Feature access and SSL validation status warnings from running the BPA.
What do these mean? Let’s look at one of the “Feature access” warnings more closely:
Figure 19: Details of a “Feature access” warning item.
This warning says we have the TenantAPI and AdminAPI installed on the same machine (WAP01) and that this isn’t a good idea for security reasons because these APIs have different levels of access. Once again however this is a non-issue for our PoC express deployment.
Let’s also examine one of the “SSL validation status” warning items in more detail:
Figure 20: Details of a “SSL validation status” warning item.
This warning says that SSL validation for AdminAPI is turned off because the DisableSslCertValidation setting is currently set to true, and that as a result of this your SSL certificates won’t be validated. Well, we’re using a self-signed certificate so let’s ignore this warning too.
Let’s look at one more of these SSL validation status warnings:
Figure 21: Details of another “SSL validation status” warning item.
This one says we’re using SSLv2 which is an insecure protocol. That’s not an issue of course for our express deployment so we can safely move on.
Conclusion
Once you’ve reviewed all the results from running the BPA scan on your express deployment of Windows Azure Pack and ignored any warnings that don’t apply to your PoC scenario, you are able to verify that Windows Azure Pack has been successfully deployed. At this point you’re ready to provision optional resource providers like Virtual Machine Clouds, which is what we’ll cover in the next article in this series.
If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
