Nick Meader's Blog https://docs.microsoft.com/archive/blogs/nick_meader/feed.xml Experiences with virtualization, SharePoint, and Enterprise Search Wed, 17 Apr 2019 03:50:11 GMT en-US hourly 1 Windows Azure Pack Configuration https://docs.microsoft.com/archive/blogs/nick_meader/windows-azure-pack-configuration Thu, 04 Dec 2014 08:29:00 GMT https://blogs.msdn.microsoft.com/nick_meader/2014/12/04/windows-azure-pack-configuration/ This is the fifth article in a series of blog posts that will guide you through a simple implementation of a self-service private cloud interface using Windows Azure Pack. There are many layers of the application, and the underlying infrastructure, when implementing this solution. As we progress through the series we will lay out a scenario, a set of requirements, and provide guidance on how to implement each of the numerous prerequisites, with the ultimate goal of a self-service portal that your team can use to create and manage their own virtual machines.

This article goes over the setting up the Windows Azure Pack user experience, including plans, services, add-ons, and other administrative tasks using the administrator interface.

Configuring WAP for our users

This entry in the series will go over customizing the services and plans that users of the private cloud have access to. In this post we will go over adding the basic services, and setup a basic plan that we can build on if additional services are added.

Useful Links

Now that we have installed Windows Azure Pack, there are three main interfaces that we will use to interact with our private cloud. Below are the links to those three interfaces

The first two sites should already be familiar, the first being the configuration site that is used to connect the WAP sites to the WAP configuration database, and the second is the admin interface. The tenant site is the site that will be used by the tenants of the private cloud. In a later blogpost, we will go over how to configure these sites with a friendly name, as well as creating a signed SSL certificate to use, removing the self-signed certificate warning when visiting these sites.

Services

Within Windows Azure Pack, there are a number of services that can be added and provided to users. In this section, we will look at adding VM Clouds, SQL Server services so that we can provide access for our users.

VM Clouds

The VM Cloud from our VMM should have been added from our previous blog post in the series.

To view the PrivateCloud that we created, click on VM Clouds, select CLOUDS. Expand the VMM server, and click the -> button on PrivateCloud.

The PrivateCloud current utilization will be shown on the Quick Glance screen. Without any utilization on the cloud, the Quick Glance won’t have much information to provide, but as utilization is increased on the cluster, the utilization table is updated to reflect the levels reported by VMM.

Even though the cloud was setup as unlimited in this case, the graph scales reflect the physical limitation of the hardware setup for the cloud.

SQL Servers

Another service that can be provided to a user is a SQL Server. A SQL Server can be added to WAP for this purpose, but only specific versions will work, including the following:

  • SQL Server 2008 SP3
  • SQL Server 2008 R2 SP2
  • SQL Server 2012 SP1
  • SQL Server 2014

When planning for the SQL Server that will be added to the cluster two points should be considered. First, care should be taken to ensure that the physical hardware, and other SQL instances are not impacted by the SQL instance used for our users. Second, when configuring external access to a new SQL server, it is important to carefully implement the firewall rules in order to avoid unintended access to the SQL instances used for administrative and configuration services in the VMM cluster.

A good option for both of these points, is to create a separate VM in the Admin Host Group on our VMM cluster. Directions for creating a VM can be found in the previous entry in this series, as well as installing a separate SQL instance and updating the firewall rules.

For our example, we are using the sqlvm1.domain.local as the hostname for our SQL Server VM.

For this instance, it is advisable to also attach a separate data disk to the VM, as the SQL Server instance can grow larger once users start creating additional databases. It is also advisable to change firewall settings to allow database access from the new VM, as well as use mixed-mode authentication. Once a SQL Server instance is created for our users from the admin portal, click SQL SERVERS -> Add an existing server.

Enter the SQL Server name, as well as the port, and enter credentials with database creation permissions on the server, and select an appropriate database size limitation. Once the SQL Server has been added, select -> to view the dashboard.

From the dashboard, you can see current utilization, as well as the active databases.

Other Available Services

Other services are also available for WAP, including Web Site Clouds, Service Bus Clouds, and MYSQL Servers. For our scenario these are not needed, but information about these services can be found at the following locations.

Plans and User Accounts

Our Windows Azure Pack portal will be self-service, and users will be able to register and add themselves in order to create VMs and services.  In order to prevent a disorganized (or chaotic) grab for resources, the administrator can create standard user Plans, a type of profile that sets limits on resources, and makes services available or not.  So that some flexibility is available in setting limits, a mechanism is available to define add-ons, or standardized resource limit increases.

Plans

To start the plan wizard, click on New, click Plan, and click Create Plan

The new plan wizard is shown, and prompts you for a name for the new plan. Enter a descriptive name, and click ->

Ensure that both Virtual Machine Clouds, and SQL Servers are checkmarked, and Click ->. Click the Checkmark to complete the wizard, and it will take you to the plan dashboard.

Before the plan is able to use the Virtual Machine Cloud, it needs to be configured. Beside Virtual Machine Clouds, Click ->

Select our VMM server, and the Cloud that we created and scroll down to the usage limit section,

Here, we can setup limitations on the resources each user is allowed to use. In this case, each user is allowed to create 2 virtual machines, with a shared 8 cores, and 16GB of memory. Scroll down to the Networks section, and click add networks

Select our VM network, and click the checkmark to return. We don’t currently have any templates, or gallery items configured for the private cloud. We will go over creating these in a following entry in the series.

Click save to activate the VM Cloud for the plan. Any user with access to the tenant portal is able to create an account, but they need to add a subscription to their account to be able to use it. Since our requirements indicate a need for a self-service interface, we have multiple options on how to add a subscription to a user’s account. We can protect our subscription with an invitation code, or allow any user to add the default subscription to their account. To add an invitation code setting, click on SETTINGS, enter an invitation code, and click Save.

To publish our new plan, and make the plan public, click Change Access, and click Public. A user with an account will then be able to see the new plan, and add it to their account assuming they have the correct invitation code, if that was configured.

Add-ons

Add-ons allow you to add additional resources to the limits of a subscription for a user if the plans are not unlimited. To create an add-on, enter the dashboard for the plan, CloudUser, and click ADD-ONS. Click create a new add-on to start the wizard

Enter a name for our new addon, and click ->

Select the services that the add-on with be modifying, and click checkmark

Click the -> beside the service to configure the settings for the add-on.

Enter the additional limits for the add-on, and click Save. Once the add-on is saved, click the <- button to go back to the add-on overview page. Click on Link a plan to add the add-on to our plan.

Select the plan we created earlier, and click the checkmark button. The add-on should now be functioning, and can be added to a user manually.

Administration

When you initially setup WAP, it will use the current user as the one and only administrator able to access the adminsite. Luckily, we can easily add additional users to help with the administration, unluckily, you aren’t able to do it from the adminsite UI, you need to configure this through the Windows Azure Pack Configuration PowerShell interface.

Adding additional administrators

To add an additional administrator, open the Windows Azure Pack Configuration PowerShell interface as Administrator. We will need a couple pieces of information to add the new user to the WAP configuration database:

  • Sql server:         host01.domain.local,<port>
  • Db username:   sa
  • Db password:    **********
  • New user:          DOMAIN\newuser

Once we have this information from our earlier steps, we run Add-MgmgtSvcAdminUser to add the user

$dbserver = ‘host1.domain.local,58920’ 
$dbuser = ‘sa’ 
$dbpassword = ‘********’ 
$newadmin = ‘DOMAIN\newuser’ 
$connectionstring = [string]::Format(‘Data Source={0};Initial Catalog=Microsoft.MgmtSvc.Store;User ID={1};Password={2}’, $dbserver, $dbuser, $dbpassword) 
Add-MgmtSvcAdminUser -Principal $newadmin –ConnectionString $connectionstring

The cmdlet should then return the new user that was added and return you to the prompt. The user should then be able to log into the admin site using their own credentials.

Finishing Up and Next Steps

At this point, we should have a self-service private cloud. Users should be able to log into the tenant portal site, create accounts, add subscriptions, and create their own VMs. Before we can easily have users do that however, there are some customizations that we can perform that will make the usage of the Tenant portal easier, by creating templates, implementing roles, and modifying the way that users access the tenant portal itself. All of these customizations will be covered in the next post in the series.

]]> Windows Azure Pack Installation https://docs.microsoft.com/archive/blogs/nick_meader/windows-azure-pack-installation Wed, 17 Sep 2014 10:35:00 GMT https://blogs.msdn.microsoft.com/nick_meader/2014/09/17/windows-azure-pack-installation/ This is the fourth article in a series of blog posts that will guide you through a simple implementation of a self-service private cloud interface using Windows Azure Pack. There are many layers of the application, and the underlying infrastructure, when implementing this solution. As we progress through the series we will lay out a scenario, a set of requirements, and provide guidance on how to implement each of the numerous prerequisites, with the ultimate goal of a self-service portal that your team can use to create and manage their own virtual machines.

This article goes over the Windows Azure Pack installation, as well as the instance specific prerequisites. After installation is completed we will also go over the initial configuration, showing how the architecture that was developed in the previous blog posts is finally connected to Windows Azure Pack.

Windows Azure Pack Overview

Windows Azure Pack is a series of websites and APIs that work together using a configuration database to manage a cloud and other services through Service Provider Foundation. There are multiple options for installing WAP, including high-availability distributed solutions and an express installation. For the purposes of our scenario an express install is all that is required, and we will install all of the components (except for the configuration database) on a virtual machine designated for WAP. For directions on how to install a distributed or high-availability WAP configuration, the following TechNet article provides
detailed information:

Install a distributed deployment of Windows Azure Pack

The Web Platform Installer can be used for any installation, from simple to complex.  For our scenario the best choice is a Web Platform Installer executable preconfigured for an express installation on a single node, with all the necessary components selected. The installer can be downloaded from the following location:

Windows Azure Pack: Portal and API Express

Note: Do not download and run this installer at this time on existing servers.  We will create a new VM to deploy this software later in this procedure.

Windows Azure Pack Prerequisites

Windows Azure Pack has a list of prerequisites that must be installed prior to the other components. The installation of most of these components will occur automatically when the installer is run. For our scenario however, we need to create a Virtual Machine to host the WAP components, as well as create a SQL instance to hold the WAP configuration database.

AD Service Accounts

For this entry in the series, we will need an additional service account to be created to run the WAP SQL instance.

  • _wap_sa – Account for running WAP SQL Instance

VM creation

For our express installation of WAP we are going to need a place to host the Windows Azure Pack components. An easy way to manage the resources of WAP is to place it on its own VM, where it is possible to control the resources allocated to the environment.

To create a new VM, from the VMM console select the following:

VMs and Services -> Create Virtual Machine from the ribbon

The Virtual Machine Wizard will start up, and allow you to select an existing VHD, or create a brand new one. In our case we have a sysprep’d Windows Server 2012 R2 VHD ready to go. Details on preparing a VHD with sysprep can be found at the following location:

Using Existing Virtual Hard Disks with Hyper-V

In our example, we select our prepared VHD, and click Next.

Here, we are simply naming our VM. In this case, the name corresponds to the hostname that will be used on the machine itself, but this is not required. Select a Virtual machine name, and click Next.

For the virtual hardware, we set appropriate processor cores, and memory, and if creating a VM from a blank disk, ensure to attach an ISO to the Virtual DVD drive as well for OS installation.

For networking, attach the Network Adapter 1 to our VM network that we created in the second post in the series, CompanyNetwork VM Network, and continue by clicking Next.

For the destination, we are going to place the new VM on the Admin Host Group that we created. Placing the new VM in this host group ensures that the performance of the portal will not be affected by the users of the cloud, since the Admin hosts are separate from the Cloud Host Group. Click Next to continue.

In our scenario, the Admin Host Group only contains one destination host, HOST1.domain.local. Select this destination and click Next.

For the Deploy Location, ensure that the path selected has sufficient space to store the VHDs that were specified, in our case the D:\ drive is our large capacity data disk on the physical hosts. Click Next to continue.

The properties of the VM allow you to select the appropriate actions when the physical host is restarted. For the Automatic actions, it is a good practice to select “Always automatically turn on the virtual machine” and “Save State” to ensure that the portal is accessible if the physical host is restarted. Click Next to continue.

This completes the VM wizard. Verify that the Start the virtual machine.. box is checked, then click the Create button to create the VM.

Note: Some post-creation tasks may need to be performed, including joining the new VM to the Active Directory Domain.

SQL Server Instance

WAP will also require its own SQL database instance. Directions on creating a database instance can be found in the first post in this series:

Installing SQL Server

We are going to install this instance on our VMM server (HOST1), which is where we are already running instances for VMM, and SPF as well. There are two places where we will want to make customizations to the instance, the instance name, and the authentication.

When you reach the Instance Configuration step, create a new Named instance, in our case we are using WAP. This instance will be used to hold the WAP configuration database. Proceed in the wizard until you reach the Server Configuration page.

For the Agent, and Database Engine services, select the service account we created earlier(DOMAIN\_wap_sa), and enter the credentials for each. Click Next.

For the authentication, we want to use the Mixed Mode authentication, and specify a password for the ‘sa’ (system administrator) user. The reason for this is because the WAP configuration will automatically attempt to use the current user if using Windows authentication mode, and this is an easy way to ensure that you can specify a specific user. Proceed with the wizard until the new instance install is complete.

SQL Server Firewall Rules

Our new SQL instance will need to be accessible from a remote location, because WAP is going to be installed on our newly created VM and the SQL instance exists on the physical host. In order to accomplish this we will need to make a Windows Firewall exception rule to allow this traffic from the VM to the new instance.

To create this rule we will need to know what port the new instance is running on. To find this information you can follow the same procedure we used when configuring the SPF configuration database in the previous blog entry:

SQL Server Instance

To begin, open the Windows Firewall with Advanced Security, and you will be greeted with the firewall interface, click on Inbound Rules, and click New Rule…

For the Rule Type, select Port and click Next.

Ensure TCP is selected, and enter the Specific local port that we recorded earlier from the SQL Configuration Manager in this section for our new instance’s dynamic port, and click Next.

Ensure that Allow the connection is selected, and click Next.

The default settings for the profiles are acceptable for our scenario, as we will only ever be connected to the domain. Click Next to continue.

Finally, enter a descriptive Name for our new firewall rule, and click Finish. Our SQL instance should now be accessible remotely using the dynamic port from the SQL Configuration Manager.

To verify access, from a remote computer, you can attempt to connect using SQL Server Management Studio using <hostname>,<port> for the server name, and SQL Server Authentication with the ‘sa’ credentials setup when creating the new instance. If SQL Server Management Studio is unavailable, a simple telnet request will also work, e.g. > telnet HOST1.domain.local <port>

Windows Azure Pack Installation

All of previous steps in all of the entries in the blog series has finally led to the point of actually installing Windows Azure Pack. The installation for Windows Azure Pack is fairly simple, simply run the Express installer available from the link in the overview above to begin the installation wizard. This wizard should be ran on the new VM we created for WAP earlier, and should be performed after all the post-installation steps (joining domain, etc.) have been completed.

Note: If it is the first time that the web platform installer is run, it may need to install itself, so the installer may need to be run a second time to install the pre-packaged WAP components. Save the installer locally to ensure the download does not need to happen twice because of this.

Once the WPI is started, click the Install button to install the WAP Portal and APIs.

The installer will check for prerequisites, and will download and install them automatically once you click I Accept.

Select an appropriate response for the Windows Update settings, and click Continue.

Click Continue to install the components on the system.

Click Finish to close the installer once installation is complete. The installer will then launch Internet Explorer as an Administrator to the WAP Configuration website, at https://localhost:30101/

The Configuration site (and all of the other sites as well, tenant, admin, etc) will warn you about the installed self-signed certificate. We will go over how to correct this warning, as well as create friendly names and ports for the portals in a later post in this series. For now, click Continue to this website, against the IE recommendation.

The configuration site will then start up a configuration wizard, enter the hostname and port for the SQL instance, separated by a comma, ex: “host1.domain.local,58920”. For the Authentication type, select SQL Server Authentication, and enter the credentials for the ‘sa’ user that were used when the instance was configured. For the Configuration Store Passphrase, select a passphrase that will be used whenever a new server is added to the WAP configuration. Click the -> button to proceed.

Note: for our scenario, the wapportal server is the only server that will be connected to the configuration database. In a distributed installation, the passphrase is used to authenticate and add new servers to the distributed installation.

Select an appropriate response to the CE program, and click ->

Click the checkmar button to start the configuration.

At this point, it should configure each of the features. Click the checkmark button to complete the wizard. At this point, the installation and configuration of the portals are complete. Our next steps will be to log in to the Administrator portal and connect WAP to talk to our VMM cluster using SPF.

Windows Azure Pack Initial Configuration

 Before users are able to start using the WAP Tenant Portal to start creating their own VMs, SQL Servers, and other resources, we need to provision the environment with the appropriate plans, and settings to let them do that. We will go over how to configure all of those settings in the next blog post in this series, but before that, we need to connect our WAP service to our VMM. We do this by accessing the Administration portal available at the following location on our wapportal server:

https://localhost:30091/

Note: By default, the only user that is allowed on the Administration Portal is the current user, or the user that Internet Explorer was running as when the configuration was completed in the last step. Directions on how to add additional administrators will come in the next post in this series.

Upon logging into the Administrator Portal for the first time, you are greeted with a wizard that explore the features of the Admin Portal.

After the wizard, you come to a fresh install of Windows Azure Pack. Currently there are no connected services for the installation. Our next step will be to connect our Service Provider Foundation to our install, which will allow us to connect WAP to the cloud we created in VMM. To begin, click on VM Clouds on the left-hand side of the portal.

Click on the SPF Registration link to open a dialog for adding our SPF settings.

Enter the Service URL for our SPF instance, which we installed on host1, using a default port of 8090, and enter the SPF service account credentials, and click the checkmark button.

The status of adding SPF will show up in the bottom bar of the portal. Click the checkmark button to dismiss the completion message.

After SPF has been configured, we need to add the Cloud that we created on our VMM instance so we can start configuring access for our users. From the VM Clouds page, click the Clouds tab, and click the -> button to start a short wizard to add the cloud provider.

Simply add the FQDN of our VMM server, host1.domain.local, and click the checkmark button to complete the wizard.

At this point, we should have our cloud listed under our VMM server, and we are ready to start setting up the service for our users.

Finishing Up and Next Steps

 

At this point, we should have a complete Windows Azure Pack installation that is ready to start configuring access for our users. The next entry in the series will review setting up additional services that we can make available to our users, and creating Plans and Plan Add-Ons that can be added to user accounts, giving them access to resources in the new private cloud. Some additional information will also be provided on extending the Administration features of the Administration Portal.

]]> Configuring Service Provider Foundation https://docs.microsoft.com/archive/blogs/nick_meader/configuring-service-provider-foundation Fri, 22 Aug 2014 07:50:00 GMT https://blogs.msdn.microsoft.com/nick_meader/2014/08/22/configuring-service-provider-foundation/ This is the third article in a series of blog posts that will guide you through a simple implementation of a self-service private cloud interface using Windows Azure Pack. There are many layers of the application, and the underlying infrastructure, when implementing this solution. As we progress through the series we will lay out a scenario, a set of requirements, and provide guidance on how to implement each of the numerous prerequisites, with the ultimate goal of a self-service portal that your team can use to create and manage their own virtual machines.

This article goes over the configuration of the Service Provider Foundation, a component in the System Center Orchestrator suite, which enables Windows Azure Pack to work with VMM to provision, and manage the private cloud. The roadmap for this and subsequent articles is:

Service Provider Foundation

A critical component in the Windows Azure Pack private cloud implementation is the Service Provider Foundation (SPF). SPF provides WAP an interface in which it can interact with the VMM cluster, including provisioning, managing, and reporting on the clouds utilization. With the use of SPF, WAP is able to create an infrastructure allowing for heavily customized, and multi-tenant solutions by utilizing the underlying VMM fabric. In our scenario, a user will be able to create an account, provision virtual resources, and manage those resources directly with WAP, without needing to interact with VMM directly, because WAP utilizes SPF.

SPF is a component of System Center Orchestrator and is available from Orchestrator’s install media. Further details on the service can be found in the following article:

Service Provider Foundation

For our scenario, we are installing SPF and the SPF SQL instance on the VMM server (host01.domain.local). This is done for simplicity, as we will not have to open additional ports on the windows firewall.

SPF Prerequisites

The Service Provider Foundation comes with its own extensive set of prerequisites. In this section, service accounts, server roles and features, and other downloads will need to be installed or configured in order for SPF to operate. We will also need to setup a new SQL instance to host the SPF database.

Service Accounts

SPF runs under its own service account. To start, a new service account will need to be created in AD for the service to operate.

  • _wapspf_sa – account for running SPF and SPF SQL Instances

This service account also needs to be added to the VMM Administrators role. From the VMM Console perform the following

Click Settings -> Security -> User Roles -> double click Administrators

Click on Members and click Add, and enter the new service account. This will ensure that the SPF service is able to access information, and provision resources on the VMM cluster.

Windows Management Framework 4.0

This install comes with 2012 R2, but if you’re using 2012, it is a required install. Requires a restart once complete. The installer can be found at the following location:

https://www.microsoft.com/en-us/download/details.aspx?id=40855&WT.mc_id=rss_alldownloads_all

and selecting the following download:

Windows Server 2012 - x64: Windows8-RT-KB2799888-x64.msu

The install is a simple install, proceed with the wizard until completed

WCF Data Services 5.0 for OData V3

This prerequisite can be found at the following location:

https://www.microsoft.com/en-gb/download/details.aspx?id=29306

The install is a simple install, proceed with the wizard until completed

ASP.NET MVC 4

This prerequisite can be found at the following location:

https://www.microsoft.com/en-gb/download/details.aspx?id=30683

This install is a simple install, proceed with the wizard until completed. Once the MVC installation completes, exit the web platform  installer, as the other components are not required.

SQL Server Instance

SPF will also require its own SQL Server Instance. Follow the directions from the first entry in this series to install a new instance using the following options:

Instance features: database engine services

  • Named instance: SCSPF
  • Sql Server Agent Account Name: DOMAIN\_wapspf_sa
  • Sql Server Database Engine Account Name: DOMAIN\_wapspf_sa

And provide access to the service account, and any applicable security groups. Proceed to install, and close once complete.

When an instance is created, a dynamic IP port is also selected for that instance. We are going to need to know this port in the next step so we will need to record it from the SQL Server Configuration Manager.

 

From the configuration Manager, expand SQL Server Network Configuration, and select Protocols for SCSPF, and double-click TCP/IP.

Click the IP Addresses tab, and scroll to IPAll, and take note of the dynamic port selected for the SCSPF instance. 

Roles and Features

The Last steps for installing the SPF prerequisites involve enabling roles and features on the server. The following article shows how to install roles and features on windows server 2012.

Install or Uninstall Roles, Role Service, or Features

The following Roles, Features, and Services need to be installed.

Roles:

  • Web Server (IIS)
    • Click OK to add additional features

Features:

  • Management ODATA IIS Extension
    • Click OK to add additional features

Web Server Role (IIS) – Role Services - Verify or add the following services:

  • Web Server -> Security -> Basic Authentication
  • Web Server -> Security -> Windows Authentication
  • Web Server -> Application Development -> ASP.NET 4.5
  • Management Tools -> IIS Management Scripts and Tools

Click Install to begin the process, and once it is complete, close out of the wizard.

Installing SPF

After all of the prerequisites are installed, we are able to start the installation. From the System Center Orchestrator installation media, run SetupOrchestrator.exe and select Service Provider Foundation from the Standalone installations section under Service Management. Click Install on the next window to start the installation wizard.

The wizard will start with a license agreement, and checking the prerequisites. The check should succeed, if it does not, check the installation status of the identified components. Click Next to move to the database configuration.

Enter the Port from the SPF SQL Instance from earlier, and click Next.

Leave the default website options, and click Next.

For the Admin Web Service, add the current user, _wapspf_sa, and any other applicable security groups for the web service administrators, and specify the _wapspf_sa service account for the app pool credentials and click Next. Repeat for provider web service, vmm web service, and Usage web service.

Select the desired responses for customer experience, and windows updates, and click Next. Proceed to Install. Click close once complete.

To verify that the SPF was setup correctly, open a browser, and go to the following site:

https://localhost:8090/SC2012R2/VMM/Microsoft.Management.Odata.svc/

The site will prompt you for credentials, enter the _wapspf_sa credentials and hit Ok. If prompted about the website's security certificate, click Continue to this website.

 

The page will provide the OData interface for SPF. Close the browser once you’ve verified the access. 

Finishing Up and Next Steps

This concludes the configuration of the Service Provider Foundation, the interface that Windows Azure Pack will use to manage resources on our private cloud. Now that the underlying infrastructure for our solution is installed, and configured, our next steps will be to create a virtual machine to host the Windows Azure Pack components, install the WAP prerequisites on the VM, and then finally install WAP and connect it to our newly installed SPF. 

 

]]> Configuring the VMM Fabric For Windows Azure Pack https://docs.microsoft.com/archive/blogs/nick_meader/configuring-the-vmm-fabric-for-windows-azure-pack Mon, 04 Aug 2014 12:52:00 GMT https://blogs.msdn.microsoft.com/nick_meader/2014/08/04/configuring-the-vmm-fabric-for-windows-azure-pack/ This is the second article in a series of blog posts that will guide you through a simple implementation of a self-service private cloud interface using Windows Azure Pack. There are many layers of the application, and the underlying infrastructure, when implementing this solution. As we progress through the series we will lay out a scenario, a set of requirements, and provide guidance on how to implement each of the numerous prerequisites, with the ultimate goal of a self-service portal that your team can use to create and manage their own virtual machines.

This article goes over the configuration of the VMM fabric in preparation for the installation of Windows Azure Pack. The roadmap for this and subsequent articles is:

Creating a Cloud

Just like a real cloud, made up of many drops of water, a computing cloud is made up of multiple virtual resources, deployed on an infrastructure composed of several physical hardware components. The collection of resources, physical and virtual, is the fabric on which a cloud service is built. Setting up the fabric on a VMM cluster can be a complex undertaking. For simplicity, only the required components for our scenario will be described. Additional features like virtualization, and port classification will be discussed later in this entry after the configuration.

A Fabric in its simplest terms, is a configuration set that allows Hyper-V nodes and their guest VMs communicate to each other, and the rest of the network. The fabric creates virtual network components, with a standardized configuration, on physical hardware on each of the Hyper-V nodes in the cluster. Once this underlying configuration is created, deployed VMs are able to each communicate with each other as if they are connected physically to the same network. Below is a list of the individual components in VMM, each linked to a descriptive TechNet article.

  • Host Group – Logical group of Hyper-V resources
  • Logical Network – A virtual network, from the physical network, to which virtual network components will be connected
  • Port Profile – A common set of configurations for virtual switches and virtual adapters
  • Logical Switch – A virtual switch connecting one or more virtual adapters to a logical network
  • Port Classification – A common set of configurations that can be used by multiple port profiles.
  • VM Network – A virtual network through which VMs are able to communicate with each other built on top of a Logical Network
  • Cloud – A common set of configurations that encapsulate the fabric, and physical resources. Allows tenants to deploy VMs while adhering to the limitations of the cloud.

Below, we are going to go over setting up each of these components while staying within the requirements of our scenario from the first entry in this series.

Creating Host Groups

A Host Group in VMM is a logical grouping of Hyper-V servers that can be reserved for specific purposes, or identified as a whole for advanced operations via PowerShell. In our scenario, we are going to create two host groups, setting aside the Hyper-V node running VMM as the Admin group, and providing the rest to our cloud. This ensures that we have a space to set up administrative VMs for services like Windows Azure Pack, or an SQL instance for tenants. To do this, we’ll create two groups in the VMM fabric with the following steps:

Click Fabric -> right click All Hosts -> create host group -> Admin

Click Fabric -> right click All Hosts -> create host group -> Cloud

When we created our VMM cluster, we put all of our hosts into the All Hosts group. To move the hosts into the appropriate group, do the following for each host:

Click Fabric -> select All Hosts -> right click host1.domain.local -> move to host group

Change Parent host group to Admin, click OK.

Repeat for remaining nodes in the cluster, moving them to the Cloud host group.

Creating a logical network

Our next step in creating our fabric for our cloud is to create a logical network. The logical network in VMM is a virtual network built on a physical network. A logical network can be simple or very complex, setting up IP address pools, DNS, VLANs, and IP Subnets for example. Our Scenario uses a DHCP server, and an existing IP address configuration, with DNS integration provided by Active Directory. This enables us to use the default settings in most cases as we create the fabric in subsequent steps.

To create the Logical networking perform the following steps:

Click Fabric -> expand Networking -> select Logical Networks -> Create Logical Network from ribbon or right-click Logical Networks to start wizard.

The start page for the Logical Network wizard provides many alternatives for how our network will ultimately be configured. In our scenario we are going to use a single connected network, without using virtualization. This means that each VM that we create should be able to connect directly to our company’s network, and should be reachable from anywhere on that network. Alternative solutions, include network virtualization, will be reviewed in the in the Alternative Options sections later in this blog entry.

To begin enter a name for the new network, e.g.: “CompanyNetwork”. Select One connected network, and click Next.

Select All Hosts from the host groups, click insert row, enter the IP subnet, e.g.: 10.0.0.0/24, click finish, and a job will be created to create the network. Here we’re using the IP subnet values provided by the underlying physical network provided for the scenario.

Port Profiles

In VMM, port profiles are containers for standard configuration and capabilities for network adapters and switches. A port profile enables VMM to setup a consistent set of capabilities for all hosts in a cluster, rather than configuring each individually.

For our scenario, we require an Uplink Port Profile. To start, perform the following:

Click Fabric -> expand Networking -> select Port Profiles -> Create Hyper-V Port Profile from create on ribbon or right-click Port Profiles to start wizard

Enter a name for our uplink port profile, select Uplink port profile, leaving default options, and click Next.

Select our previously created network site CompanyNetwork_0 created automatically when we created on our logical network CompanyNetwork, and hit next.

Click Finish to complete the wizard, and the new Uplink Port Profile will be available from the Port Profiles networking section.

Logical Switches

In VMM, a logical switch is a virtual switch configured and placed on each Hyper-V host. This group of switches allow the virtual network adapters that connect to it to appear they are connecting to the same device in the fabric. To create our logical switch perform the following:

Click Fabric -> expand Networking -> select Logical Switches -> Create Logical Switch from ribbon, or right-click Logical Switches to start wizard

 

The getting started page describes the basic functionality of the logical switch, as well as the prerequisites, which we have luckily covered in the previous sections. Click Next to continue.

 

Enter the switch name, “CompanyNetwork Switch” and click Next.

Leave default extensions selected, and click Next.

On the uplink profiles page, click Add.

Select our port profile CompanyNetwork Uplink and click OK.

Once uplink port profile is added click Next.

On the port classifications page, click Add, and click Browse

 

Select High bandwidth, and click Ok

Select Include a virtual network adapter port profile, and select the High Bandwidth Adapter and click Ok

Once the port classification has been added click next. Alternative options for port classifications can be found in the Alternative Options section

Click finish on the summary page, and the wizard will close, and create a job to create the new logical switch

Create VM Network

Now that the virtual network components have been created, we need to create a VM network. A VM Network is a virtual network created on top of the Logical Network in our fabric. As mentioned before, VMM provides much functionality that our scenario does not require, such as creating multiple virtual networks with different capabilities over the logical network. In our example we are only using a single VM Network however. To begin, perform the following:

Click VMs and Services -> Create VM Network from ribbon, or right-click VM Networks to start wizard.

Enter a descriptive Name, select the created logical network “CompanyNetwork”, and click next. Click finish to finish the wizard, and a job will be created to create the new VM network. 

Configuring Hyper-V nodes with new fabric

Once all the networking components are configured in VMM, it is time to configure the virtual networking components to the physical networking components on each of the Hyper-V nodes.

Note: Performing these steps can interrupt networking activity on the physical machines, and physical access to the machines may be required to repair network connectivity if any of the VMM jobs fail.

To begin, perform the following:

Click Fabric -> All Hosts -> right click host1.domain.local -> Properties -> Virtual Switches

Click New Virtual switch -> New Logical Switch and to select the previously created Logical Switch and Uplink Port Profile.

Click New Virtual Network Adapter, enter CompanyNetwork for the adapter name, and select the physical inheritance option. Select the port profile “High bandwidth” for our logical switch and click OK. The inheritance option will reuse the existing network configuration from the physical adapter on the new virtual adapter. You will get a warning that you may temporarily lose network connectivity, which you will need to confirm. A Job will be created to apply the new changes to the node. If the job is unsuccessful, physical access to the machines may be required to reconfigure the physical network components.

Once the job has completed some networking changes will have been made on the physical node.  The original network adapter device is now configured solely as a Hyper-V Extensible Virtual Switch, and a new vEthernet adapter has been created.  This new device is configured with the configuration settings (e.g. protocols, IP and DNS values) from the original physical adapter.

This process will need to be repeated for all Hyper-V servers in the VMM cluster.

Creating the Cloud

Now that the virtual networking components have been configured and linked to the physical components in the cluster, the final step is to establish a cloud on the new fabric. The cloud allows you to create a logical grouping of all of our new components, as well as setup resource limitations if needed. In our previous steps, we created only what was necessary for our single cloud, so many of the options for configuring our new cloud will seem straightforward. To begin, perform the following:

Click VMs and Services -> Create Cloud from ribbon, or by right clicking clouds to start the wizard

Start by selecting a name for the new cloud. In our example, we are creating a single private cloud so we set the name to something simple, PrivateCloud. Click Next.

For our purposes, we only want to select the Host Group that we set aside for the cloud in the previous steps. This allows us to keep a set of physical machines (the VMM node Hyper-V instance) for our own purposes, without creating utilization on the cloud Host Group. We will use the Admin Host Group later to create the WAP portal, as well as additional WAP services, like SQL Server. Select Cloud and Click Next.

Select the logical network that we configured earlier, CompanyNetwork, and click Next.

Continue on the wizard by clicking Next on the LoadBalancer configuration, and VIP Templates pages, until you get to the Port Classifications.

Select the High Bandwidth port classification we used earlier, and click Next

Select Local Storage, and click Next.

Click Add, and select the MSSCVMMLibrary value configured during the original VMM installation, and click OK and click Next

Setup any limitations on resources that you require. In our scenario, the host group that we set up is set aside for only the cloud, so we are leaving most settings as Unlimited, though in actuality the resources of the underlying Hyper-V will impose limits. Click Next.

Leave all capabilities checkboxes unchecked. Selecting capabilities at this point will create issues when WAP attempts to use the cloud later. Click Next and then click Finish. Once complete a Job will be created, and the cloud will be configured.

Alternative Options

The following sections contain alternative options for our simple scenario. The ability to customize the fabric in VMM will allow you to cater the implementation based on your own requirements.

Network virtualization

In System Center 2012 SP1 + R2, Network Virtualization was developed. The idea behind virtualization is it allows you to encapsulate an entire virtual network, allowing for multi-tenant configuration, inside a VM/Logical/Physical network. Additional details around network virtualization can be found in the following article

Hyper-V Network Virtualization technical details

Port classifications

In a complex VMM architecture, there may be multiple physical connections, logical networks, and virtual hardware. Each of these networks can have multiple roles, like high-availability, live migration, administrative, tenant, etc. Each of these can be set up with different port classifications and associated port profiles, enabling you to shape the traffic between physical and virtual hosts. More details on how to configure Ports and Switches can be found in the following article

Configuring Ports and Switches for VM Networks in VMM

Finishing Up and Next Steps

This concludes the configuration of the VMM fabric, with a functioning VMM cluster prepared for the next steps in deploying Windows Azure Pack. Our next steps will be to add the Service Provider Foundation, a necessary prerequisite for WAP, and other preparations for installation.

]]> Building a self-service private cloud using Windows Azure Pack https://docs.microsoft.com/archive/blogs/nick_meader/building-a-self-service-private-cloud-using-windows-azure-pack Thu, 31 Jul 2014 09:05:00 GMT https://blogs.msdn.microsoft.com/nick_meader/2014/07/31/building-a-self-service-private-cloud-using-windows-azure-pack/ This is the first article in a series of blog posts that will guide you through a simple implementation of a self-service private cloud interface using Windows Azure Pack. There are many layers of the application, and the underlying infrastructure, when implementing this solution. As we progress through the series, we will lay out a scenario, a set of requirements, as well as provide guidance on how to implement each of the numerous prerequisites, with the ultimate goal of a self-service portal that your team can use to create and manage their own virtual machines.

This article defines our scenario and requirements, general architecture, and prerequisite installation. The roadmap for this and subsequent articles is:

Scenario

Your team is in need of a private cloud. System Center Virtual Machine Manager 2012 (VMM) provides the functionality required, but that solution requires a high administrative effort to configure VMs for users as needed without providing privileges to the user directly on the VMM cluster. VMM lets you build a "fabric" consisting of multiple resources, both physical and virtual. The underlying fabric can then be utilized by the administrator to create a virtual environment for users. Enter Windows Azure Pack (WAP). WAP provides the ability for users to create their own virtual machines, databases, and other resources through a familiar Windows Azure type interface, utilizing your own VMM cluster hardware and the fabric that was setup on the VMM cluster.

Together VMM and WAP provide a lot of functionality to truly deliver a custom solution, including tenant configurations, virtualized networking, even monetization of your private cloud. Most of these features go above and beyond what we need for our requirements. In the following sections we'll go over the individual requirements for our scenario, as well as describe the existing architecture that we have available.

Hardware

In our scenario, we have a set of 5 physical nodes, with the following hardware:

  • Windows Server 2012 (R2 Preferred)
  • 24G of ram
  • 16 logical cores (2x Intel® Xeon® CPU L5630 @ 2.13GHz)
  • 1 single connected Ethernet connection
  • 8x 300GB 10K SCSI disks in a RAID5 configuration, 1.86TB Usable Disk

The size of the VMM cluster and the number of nodes that we have available isn’t an actual requirement. While our hardware may not be ideal for a VMM cluster, it’s what we have available in this scenario. This gives us a cluster with over 100G of ram, 80 Cores, and over 9TB of direct attached storage. A solution could be as simple as a single-node Hyper-V cluster, managed by VMM, with a VM hosting the other required components, including WAP and SQL.

Note: All of the physical machines in our solution are domain joined machines.

The default configuration of our machines in our scenario have a single OS disk (C:) and a single large-capacity data disk (D:).

Networking

In our example, we have a predefined network which was provided to us. This could be as simple as the team’s current network. The network in our scenario provides a range of IP addresses by DHCP, as well as a DNS server. In our example, we are going to need to be able to create our own DNS entries, which means we’ll either need our own DNS server, or the ability to add our own entries to the existing DNS server. Each machine has a single Ethernet connection, so extra care will need to be taken when configuring the virtualized networking for our cluster.

Architecture Components

There are many components that make up the architecture, below is a list of some of the major components that we will be utilizing our solution.

This article will assume that there already is an AD DS with an established domain that is available to us and that we are a Domain Admin on this domain. We will need to be able to add service accounts as well as create DNS entries on the DNS server.

 

Prerequisite Installation

 Following are the steps that need to be performed to install VMM on our new Windows Server 2012 R2 cluster.

AD Service Accounts

Along with your account, which requires membership in the Domain Admins group, there are a number of service accounts that will need to be created for the different services in our configuration. For this step in the series however, the VMM service account, and VMM SQL service account are the only required service accounts for this step in the series however.

  • _wapvmm_sa – Account for running VMM
    • Cannot be changed once VMM is installed
    • Must be a member of the local administrators group on VMM node
  • _wapvmmsql_sa – Account for running VMM SQL Instance

Hyper-V

Our first step in setting up our VMM cluster is to get all of the nodes in the cluster setup with the Hyper-V role. The following TechNet article goes over the installation of the role:

Install Hyper-V and Configure a Virtual Machine

Install the role on all of the servers in the cluster which will be hosting virtual machines. Final configuration of the Hyper-V settings will come later when the VMM service is installed and configured.

SQL Server

VMM requires its own instance of SQL Server to hold the status and configuration of the VMM cluster. This section will go over a basic installation of SQL, with the settings required by the VMM service. In this case, we are installing the SQL Server instance on the VMM node directly. Additional SQL server instances can also be installed here for the other components (WAP or for cloud resources for example) as well, but this is not required.

To start, run setup.exe from the SQL Server 2012 installation media, click Installation, and click New SQL Server Standalone Installation to start up the installation wizard.


 
The wizard starts by running a few checks, which may result in a warning about the Windows Firewall rules. This warning can be safely ignored, as we will not be accessing the VMM database remotely.


 
Proceed by clicking Next.

Enter the product key, or select the edition of SQL Server to install, and click Next.


The Wizard will then prompt you for License Terms, Windows Updates settings, and may prompt you for Customer Experience settings. Proceed through the wizard until it installs the setup files, and prompts you for feature selection. For the feature selection, select the following features, and hit Next:

  • Instance Features -> Database Engine Services
  • Shared Features -> Management Tools -> Complete

For the Instance configuration, specify a Named instance, and modify the root directory to use if other than the OS disk if disk space is an issue, and hit Next.


 
The Server Configuration requires us to select our service accounts that were created for VMM. Under Account Name, click the box and browse to select the service account created above, DOMAIN\_wapvmmsql_sa, and specify the service accounts password. Do this for the SQL Server Agent as well as the SQL Server Database Engine, and click Next.


 
The Database Engine Configuration page allows you to specify users who can access the database directly. You can specify Mixed Mode Authentication, setup a password for the sa (system administrator) account, or just use AD. In our case, we are specifying the current user, as well as an AD security group.


 
Proceed with the wizard, and install all of the selected features. Click close once the installation is complete.

Windows Assessment and Deployment Kit (ADK)

There are several features from the Windows Assessment and Deployment Kit that are required for VMM. The following link is the download page for the ADK

Windows Assessment and Deployment Kit (ADK) Download

Once the installer is downloaded, run adksetup.exe. Use the default installation paths, and click Next.


 
The installer will prompt you for Customer Experience settings, and License Agreement. Proceed with the installer until you reach the feature selection page. Select the Deployment Tools, and Windows Preinstallation Environment, while unchecking any other settings as seen below. Proceed by clicking Install.


 
Note: this process may take a while to complete

Click close once the installation has completed.

Virtual Machine Manager

Once all the VMM prerequisites are set up, we are able to install the VMM service itself. Open the installation media by clicking setup.exe, and click on Install to bring up the installation wizard. On the feature selection page, select VMM management server, and click Next.


 
Specify your organization settings, and enter the product key for System Center, and click Next.


 
The wizard will then prompt you through the License Agreement, Customer Experience settings, Microsoft Update settings, and installation location. Proceed through these steps until you get to the Database configuration. For the Server name, select the FQDN of the server where the VMM SQL instance was installed (in our case, this was the VMM server itself). Select our named instance from the Instance name menu, and click Next.


 
On the Configure Service Account page, we will set up the credentials that VMM will be running under. Select Domain account, and click select to specify the account DOMAIN\_wapvmm_sa, and enter the service accounts password.

Note: This service account must be added to the local administrator group on the VMM node.

Note: Once this account is specified, it cannot be changed unless the service is uninstalled and reinstalled

Proceed to the port configuration by clicking Next, accept the default port configuration, and proceed to the Library Configuration by clicking Next.

For the Library Configuration, change the default share location to a location on the data disk. Click Next and proceed to the Install. Once the installation is complete, click close, and the VMM console will start.

Initial setup of VMM

Once all the prerequisite software and VMM service are installed, the next thing to do is to define the Hyper-V servers that will be managed by VMM. To do this, click on Fabric -> Add Resources -> Hyper-V Hosts and Clusters and a resource wizard will start up. Select the option for Windows Server computers in a trusted Active Directory domain, and click Next. For the credentials, either specify a new Run As account, or enter credentials with appropriate permissions on the nodes. In either case, the credentials will need to be a user with administrative access to the machines, such as a user added to the Administrators or Domain Admins groups. This user may be separate from the service account created above. In our case, we are using our own user account, which is a member of the Domain Admins group, which provides administrative access to all machines in the VMM cluster.


 
Click Next to begin the discovery of hardware.

To select the hardware for the cluster, for ease, select Specify an Active Directory query, and click Generate an AD query. Enter your host prefix, and hit ok to show the AD query.


 
Click Next to select the target servers.


 
Add a checkmark next to the appropriate servers and click Next.


 
Leave All Hosts selected for the Host Group, as we can modify this later while we are configuring the fabric. Select Reassociate this host... to ensure that the agent installed on the Hyper-V nodes are correctly configured for this VMM. Select the correct placement path (preferably on a data disk), and click add, and click Next.


 
The wizard will then create a job for each VM in the cluster, and once all have completed, all should be visible under Fabric -> Servers -> All Hosts.

Finishing Up and Next Steps

At this point, we should have a functioning VMM cluster, with a default fabric. Creating VMs at this point may not provide optimal results, as the fabric has not yet been configured. Our next steps will be to prepare the fabric on the VMM cluster to prepare for WAP. Creating the fabric for WAP includes configuring the virtual network components on the Hyper-V nodes using VMM, creating a virtual network, and installing the Service Provider Foundation, which allows WAP to interact with the VMM cluster.

 

]]>