Error 500 in Azure Pack when using ADFS

I’ve had a couple of customers lately who’s had sudden issues with Azure Pack reporting a error 500 when used in combination with ADFS after logging on.

It’s because the ADFS Certificate has been updated and the thumbprint in WAP doesn’t match the one presented from ADFS anymore.

Mark has made a great post about it here (all credits to him for the solution): Error 500 Azure Pack tenant portal – Jwt10329 Error

I’ve modified Mark’s script a little bit so I can easily run it at various customers without modifying the URL’s. It will basically read the old value from the config and re-use that hostname for the ADFS dns entry.

This script assumes you are using ADFS for both the tenant and admin sites.

Just update the HOST, Username and Password and run the script on the AdminSite server. When done, logon to AzurePack as normal.

 

URL Rewrite (redirect) of HTTP to HTTPS with Powershell script

When deploying Web Application Proxy as a frontend to for example ADFS and Windows Azure Pack, or other services, the current version of Web AppProxy only supports HTTPS urls. It’s possible to use the “URL Rewrite” module for IIS to redirect users from HTTP to HTTPS. There are plenty of guides on internet on how to do that.
But I wanted to add that configuration to my WebApplication Proxy configuration script, and couldn’t find any powershell examples, so here is the script I’ve made.

It will use Web Platform installer to install the URL Rewrite module, then add the IIS Web Management tools, and in the end create a Global Rule redirecting all HTTP requests to HTTPS without the user noticing it.

 

 

Automatically Assign Availability Set Names to VMs with Powershell

This blog-post is about using System Center Virtual Machine Manager (SCVMM) Availability Sets to spread similar VM’s to different Hyper-V Hosts to increase reliability both when using Failover Clustering, and when using stand-alone Hyper-V hosts.

First of all, what is Availability Sets?
In SCVMM 2012 SP1, Microsoft added Availability Sets. Failover Cluster Manager users are probably familiar with AntiAffinityClassNames, and Availability Sets are a very similar concept. This allow the user to specify a set of VMs which they would prefer to keep on separate hosts, and the Intelligent Placement engine works hard to make sure that all our features respect that preference.

Attempting to place multiple VMs with the same Availability Set onto a single host will generate a placement warning, meaning that the host will be prioritized last in the placement dialog

  • When placing a VM with an Availability Set into a cloud placement or as part of a service will avoid hosts with another VM from the same Availability Set, and warn the user if that was the only choice.
  • Dynamic Optimization will never move 2 VMs from the same Availability Set onto the same host. It will also actively attempt to separate any VMs with the same Availability Set that are on the same host.
  • Power Optimization will never power off a host that would lead to 2 VMs with the same Availability Set sharing a host.
  • Putting a host in maintenance mode will attempt to spread VMs with the same availability set to different target hosts.
  • If your VMs are highly available and hosted on a Hyper-V failover cluster, VMM will create AntiAffinityClassNames on the VMs with an Availability Set, so that even during cluster failover, SCVMM opt to failover to different hosts, if possible.

You can manually create ASCVMM2vailability Sets through SCVMM by selecting Properties on a VM.
Just click Create to make a new Name and assign it to the VM’s you want to keep on separate Hosts. When a Availability Set is not assigned to a VM any longer, the Availability Set will be deleted automatically, thus cleaning up the list for you.

For example, for your SQL Server Cluster, you may want to create a Availability Set name called SQL and assign it to your SQL Server Nodes. Easy!
Also, if you are using Service Templates, you can opt in to automatically create Availability Set names for your services.

Though I like to control things like SCVMM1that automatically. Depending on your naming convention for your Virtual Servers, this might or might not be possible for you.
In our case we have a strict naming policy to name servers with:
PREFIX FUNCTION NUMBER as seen in this picture:

Which makes it very easy for me to define that all servers called CLAZSQ* are similar and should be kept on different servers.

But, if all servers were called SRV0001-SRV9999 it would not be possible to utilize the ServerName for setting Availability Set names, and you would have to query the CMDB for info first.

Also, in our environment we have multiple Tenants, who could each have servers called DomainController01 and DomainController02. So just having a availability set called DomainController, would not be enough. I have to make it DomainController_TenantName or something similar.

I wrote this quick and short Powershell script to automatically assign a Availability Set to all VM’s. It will remove Numbers from the VM Name, and use the VMName + UserID (Tenant Subscription id) as the Availability Set Name. Clean, simple and easy, just schedule it to run regularly, or even make a SMA Job to trigger when a VM is created through AzurePack.

And then trigger an Host Cluster Optimization of all Clusters in the Environment if you don’t want to wait for the normal one.

 

 

VM Usage History fixed in UR7

I just noticed that the VM Usage History has been fixed in UR7. It’s been broken as long as I remember and used to only show the last 3 days of data, even if you selected 1 month. I don’t think it was mentioned in the ChangeLog for UR7?

AZ1Yay!

Set or change Owner on a VMM for SCVMM and Azure Pack

Here is a updated script for modifying the owner of a VM, and/or to make it show up in Azure Pack. For a VM that’s been created in VMM to show up in AzurePack, it has to be assigned to a (not part of these scripts) Cloud and a subscription has to be added as owner to the VM (this is done by the scripts below).

Here is the original post: http://www.isolation.se/script-for-importing-existing-vms-into-azure-pack/

And here are the updated scripts:

The script will ask you for a Cloud and list the subscriptions you can choose from, and then ask which VM to set the Owner on.

The difference here is that it will also set the VMM Administrators as an Owner so you can do maintenance tasks on the VM from VMM without modifying ownership back and forth.

And then a second script that will just set the same Owner on all VMs in a cloud. It’s nice when you have a lot of existing VM’s in an environment and would like to assign them to one specific user/subscription in one go.

Both of the script are written to be executed on the VMM Server, though you can probably change the $ENV:COMPUTERNAME to point to your VMM Server and then execute the script remotely.

 

The request size exceeded the configured MaxEnvelopeSize quota

Today when I was updating our AzurePack WebSites Servers, I got an error which prevented the upgrade of most of the WebSite Roles like these;
Management Servers, Publishing Servers, Front End Servers and all the Web Workers. Yes, everyone except the Web Sites Controller.
Resulting in some unexpected downtime.  Luckily, all that was affected was this blogsite.

The error message I got was;
The WinRM client sent a request to the remote WS-Management service and was notified that the request size exceeded the configured MaxEnvelopeSize quota.
And I could also see that the files being copied to c:\windows\temp (WebFarmAgent.msi) were broken.

I also had an error “Failed to copy role artifacts to agent” in the logfile seen on Windows Azure Pack Websites Controller.

First of all, I ran this command in an Elevated Command prompt on the server hosting the Controller Role;
C:\Windows\system32>winrm g winrm/config

winrm1

And then the same command on one of the failing servers;
C:\Windows\system32>winrm g winrm/config

winrm2

Notice the difference in MaxEnvelopeSizekb between the servers. One of the other servers had MaxEnvelopeSizeKB set to 700.

I don’t know why it’s different between the servers or what has suddenly changed it, my guess it’s some Windows Update patch. Though it’s the same patches being installed on all the servers, and I’ve seen three different values. Wicked.
So by using the same value on all the servers I got the setup to work. And as you can see, this blog site is now also running. YAY!

I chose to set the value to the same as on the Controller Server which is the one trying to run the commands and copy the files to the other servers.
winrm set winrm/config @{MaxEnvelopeSizekb=”8192″}
It will now take 5-60 minutes for all update and repair jobs to complete.

I couldn’t find any Group Policy object to use to set that value as a default value on all AzurePack WebSites servers. So I’ve got to come up with another longterm solution. Maybe doing it with Desire State Configuration (DSC) or via Configuration Manager?

Moving your WordPress site running in Microsoft Azure to Azure Pack

Drum Roll please ….

I’ve now moved my blog from Microsoft  Azure to our own Private Cloud running on Windows Azure Pack!  Hurray!

azpack1

It was a really smooth transition, involving a couple of very easy steps to maintain all blogposts, media and comments.

  1. Provision a new WordPress Blog in Azure Pack.
  2. Login to WordPress to finish the installation.
  3. Upgrade WordPress (to the same version as your old wordpress site).
  4. Add the same Themes as on your old site.
  5. Install WP Clone plugin (free) on both the old and the new wordpress site.
  6. On the old blog, use the WP Clone plugin to make a Backup. When it’s done, you will get a URL, save that.
  7. On the new blog, use the WP Clone plugin to import the Backup from the URL you got in the previous step.
  8. In the new site, update your sites URL’s. In my case, I chanced isolation.labcenteronline.com to www.isolation.se.
  9. Update your DNS points, to point to your private cloud url (in my case, isolation.labcenteronline.com).
  10. Done!

 

Script for importing existing VMs into Azure Pack

As you start working with Azure Pack, you probably realize that you have a lot of existing VM’s that you would like to import into Azure Pack, and by that be able to use them just as you can handle all new ones?

All that’s needed for that, is to set the correct AzurePack user as the owner and SelfServicUuser on that Virtual Machine. And of course, have the machine in the correct “Cloud”.

Here is a small script which will help you out by;

  1. Asking in a Grid View, which Cloud you would like to import a machine in.
  2. Ask which user that should be the new owner of this VM.
  3. Let you pick, which VM from the Cloud you would like to import.

As we have multiple clouds, and users can have multiple subscriptions, I chose to make the script use GridView, to minimize the risk for human errors (typos).

 

Azure Pack : Tenant Site automatic installation

If you want to install Azure Pack : Tenant Site in a distributed installation meaning not an Express installation on just one server. It’s possible to do it manually, OR … of course in a scripted way, so it’s automatic, scripted and unattended. Same result each time and smallest amount of time wasted on installations.  Here is a small powershell script that will take care of all the dependencies and install all the packages for the Public Tenant Site.