Microsoft Product Use Rights (PUR) document update; great news for Windows Azure and hosters

What is Product use Rights (PUR)?

from microsoft.com:

“When you purchase a software license through a Microsoft Volume Licensing program, the terms and conditions for how you can use the software are defined in the Volume Licensing Product Use Rights (PUR) document, Product List document, and program agreement. The PUR is updated quarterly.”

The change

Effective January 1 2014 Microsoft made a pretty significant change to the Software Assurance benefit. This is from the Windows Server 2012 R2 Remote Desktop Service Licensing Data Sheet:

RDS User CALs Extended Rights through Software Assurance
Today, RDS CALs permit remote access to the Windows Server GUI (Graphical User Interface) running on a customer’s on-premise server and RDS SALs (Subscriber Access License) if running on a shared-server environment. Effective January 1 2014, RDS User CALs will have Extended Rights through Software Assurance. In addition to the on-premise access, RDS User CAL customers will also be able to access the Windows Server GUI running on Windows Azure or on a third party’s shared server, without acquiring a separate RDS SAL.

To leverage this benefit customers should meet following requirements:

    • Maintain Software Assurance coverage on the RDS User CALs
    • Use dedicated VOSE (Virtual Operating System Environment) in Windows Azure or third party’s
      shared servers
    • Access Windows Server session-based desktops and/or applications running on shared server
      environments
    • Limit access by internal users only i.e. by company employees, vendors and contractors and not by
      external users such as customers
    • Assign each on-premise RDS User CAL to the same named user on Windows Azure or a third party’s
      shared servers

This RDS User CAL Software Assurance benefit allows each User to access RDS functionality only on one shared server environment (i.e. Windows Azure or a third party server) in addition to access the respective on premise servers. The customer must acquire extra RDS SALs (Subscriber Access License) if the same User needs to access RDS functionality on additional shared server environments.

This is indeed great news for all customers wanting to access a remote Windows Server Desktop in Windows Azure or at another third party hoster.

More info:

Quickly stop and start your Windows Azure lab

Introduction

I needed  way to easily stop and start my different lab setups in Windows Azure. I don’t want to keep running, and pay for, a set of VMs I use maybe once a month. So here is a PowerShell script to stop and start a set of Azure VMs. One important dimension here is the order in which the VMs start (and possibly; shuts down, depending on your setup). Since all IP addresses are dynamically allocated in Windows Azure I had to make sure that my VMs started in a specific order and that the script executed synchronously. That way whatever IP they had when they were provisioned would most likely be assigned to them when they started. Therefore the script includes code to start and stop VMs in the order you specify them in the input file. It also tries to wait until the current VM is fully started or stopped before proceeding with the next one.

Pre-requisites, input file and usage

The input file is really simple. It is a text file with a Cloud Service name and a VM name on each line, separated by a semi-colon, no header:

<cs name>;<vm name>

The VMs in the file will be started in the order they are listed and stopped in the reverse order!

By default, the script looks for a txt file in its execution directory called Control-AzureVMs.txt. If it is not found PowerShell throws an error. You can override this behavior by specifying your own file with VMs to either start or stop.

You must already have your machine configured to use Windows Azure PowerShell and specify your subscription in the script:

Select-AzureSubscription “<your subscription name here>”

Whether you want to start or stop a set of VMs is controlled by a script parameter. You use either Stop or Start. Optionally you can add your own txt file with VMs after the Start/Stop parameter.

Usage with the default input file:

Control-AzureVMs.ps1 Stop

Control-AzureVMs.ps1 Start

Usage with the custom input file:

Control-AzureVMs.ps1 Stop MySetOfVms.txt

The code

Here is the code. I can think of all sorts of improvements, but I needed this quickly so that will have to wait. Error checking is pretty much non-existent at this point so use at your own risk. I accept no responsibility whatsoever.

https://gist.github.com/morgansimonsen/8529297

UPDATE: With the release of the Windows Azure PowerShell module v0.7.3 you can now create DHCP reservations for your VMs that will persist when the machine is deallocated. Check out Get-AzureStaticVNetIP, Set-AzureStaticVNetIP, Remove-AzureStaticVNetIP and Test-AzureStaticVNetIP.

NIC 2014 Slide deck

Here is my slide deck from the Nordic Infrastructure Conference (NIC) 2014. My talk was called Modern authentication for the Cloud Era and covered claims based authentication and some common scenarios, OAuth and OpenID Connect. Thanks to everyone who attended my session. Hope to see you there next year!

http://www.slideshare.net/MorganSimonsen/nic-2014-modern-authentication-for-the-cloud-era

Delegating computer object management tasks

Introduction

The subject of delegating permissions in Active Directory for management of computer objects has been covered many times in many forums. I wanted to try to collect all that information as well as add some refinements of my own.

Rights vs. permissions

In the olden days, back when I was just a wee lad and Windows NT was new, the ability to join a computer to a domain was controller by a user right called Add workstations to domain. This user right is only valid on domain controllers. Any use who had this right could join computers to a Windows NT domain. The user right still exists and is in use even on Windows Server 2012 R2 Domain Controllers running Active Directory domains. When users join their computers to the domain using their own credentials they do it using this user right. It is, in fact, the only option available to them, since no regular users are granted any permissions over computer objects in Active Directory by default.

Back in the NT era this right was granted to the Users group and there was no limit to how many computers any give user could add to the domain. When Windows 2000 came along and with it Active Directory the user right was changed to apply to the Authenticated Users security principal and any one user could only add 10 computers to a domain by default. But the preferred way for Active Directory was to use permissions in the directory service to control object creation, modification and deletion…

Active Directory has a very fine grained permissions set allowing you to set permissions for objects as well as their properties. These permissions work the same way as the rest of the authorization model in Windows does by using Access Control Lists (ACL) with security principals and their permissions listed in individual Access Control Entries (ACE). Permissions can be granted anywhere in the hierarchy and inherited down to objects and containers. Granting permissions in Active Directory to someone or something is often called delegation. Computer objects are of course also included in these permissions and we can create much better delegation of control than we could with just a global user right.

We’ll cover three delegation of control scenarios regarding computer object management in this post:

  1. Allowing a security principal to join (add) a computer to a domain
  2. Allowing a security principal to join and re-join a computer to a domain
  3. Allowing a security principal to rename a computer in a domain
  4. Allowing a security principal to move computer objects in a domain

You can of course combine any of these.

Creating a computer object and changing its properties is what is required to join a computer to the domain. The container could be the Computers container or any other OU or container, including the domain itself but I do not recommend that.

When a computer joins an Active Directory domain without specifying a path, it is placed in the Computers container. The Computers container is not an OU and so it cannot have Group Policy Objects linked to it or have sub containers or OUs. If you are fine with all computer objects being created in this container you can delegate the permissions below to the Computers container

1. Allowing a security principal to join (add) a computer to a domain

First out is the most common scenario; join a computer to an Active Directory domain. As stated earlier it is not necessary to delegate this to regular users since the very few cases where they join their own computers to a domain should be covered by the Add workstation to domain user right. One exception to this is if you want to tighten down security and remove all security principals from this user right. In that case, if you still want to allow regular users to be able to join computers to a domain you have to delegate permissions to them. The more common case is that whatever deployment solution you use adds the computers to the domain. This is by far the best solution since very few users have any idea what a domain is.

A best practice is to create a service account used only for adding computers to the domain. This account should be clearly labeled, have a strong password and not have any other rights or permissions in you directory except the ability to join the domain. That being said the procedure below works for any security principal you want to delegate permissions to join the domain for.

  1. Identify the security principal that you want to delegate permissions for
    This can be any security principal; user, group etc.
  2. Identify the container or OU where you want to allow users to manipulate computer objects
  3. Right click the container or OU you selected and select Delegate Control…
    image
  4. The Delegation of Control Wizard opens, hit Next
    image
  5. The Users or Groups window opens:
    Select the security principal you want to grant permissions to, then hit Next again.
    image
  6. The Tasks to Delegate window opens:
    Select Create a custom task to delegate and hit Next
    image
  7. The Active Directory Object Type window opens:
    Select Only the following objects in the folder and select Computer objects, select Create selected objects in this folder and finally hit Next
    image
  8. The Permissions window opens
    Select Property-specific and select Read All Properties. This is actually redundant since this permissions are already granted to the Authenticated Users principal, but the delegation of control wizard will not let you continue without selecting something on this screen.image
  9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
    image

    Delegation of Control Wizard Summary

You chose to delegate control of objects
in the following Active Directory folder:

    saferoad.com/Computers

The groups, users, or computers to which you
have given control are:

    Domain Join Account (SvcJoinComputerToDom@saferoad.com)

They have the following permissions:

    Read All Properties

For the following object types:

    Computer

    The selected principals can now join computers to the domain.

2. Allowing a security principal to join and re-join a computer to a domain

    The second scenario; allowing a principal to also re-join a computer to a domain requires some additional permissions. This is useful if you want to have a service account that can manage all computer accounts, also existing ones. System Center Configuration Manager for example requires these permissions.
  1. Identify the security principal that you want to delegate permissions for
  2. Identify the container or OU where you want to allow users to create and configure computer objects
  3. Right click the container or OU you selected and select Delegate Control…
    image
  4. The Delegation of Control Wizard opens, hit Next
    image
  5. The Users or Groups window opens:
    Select the security principal you want to grant permissions to, then hit Next again.
    image
  6. The Tasks to Delegate window opens:
    Select Create a custom task to delegate and hit Next
    image
  7. The Active Directory Object Type window opens:
    Select Only the following objects in the folder and select Computer objects, select Create selected objects in this folder and Delete selected objects in this folder, and finally hit Next
    image
  8. The Permissions window opens
    Select Property-specific and select these individual permissions:
    – Reset Password
    – Read and write Account Restrictions
    – Validated write to DNS host name
    – Validated write to service principal name     
    image
  9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
    image

      Delegation of Control Wizard Summary

    You chose to delegate control of objects
    in the following Active Directory folder:

    <domain>/Computers

The groups, users, or computers to which you
have given control are:

    Domain Join Account (SvcJoinComputerToDom@<domain>)

They have the following permissions:

    Reset password
    Read and write account restrictions
    Validated write to DNS host name
    Validated write to service principal name

For the following object types:

    Computer

    The selected principals can now join computers to the domain as well as re-join computers when the computer account already exists.

3. Allowing a security principal to rename a computer in a domain

Here goes no. 3…

 
  1. Identify the security principal that you want to delegate permissions for
  2. Identify the container or OU where you want to allow users to create and configure computer objects
  3. Right click the container or OU you selected and select Delegate Control…
    image
  4. The Delegation of Control Wizard opens, hit Next
    image
  5. The Users or Groups window opens:
    Select the security principal you want to grant permissions to, then hit Next again.
    image
  6. The Tasks to Delegate window opens:
    Select Create a custom task to delegate and hit Next
    image
  7. The Active Directory Object Type window opens:
    Select Only the following objects in the folder and select Computer objects and hit Next 
    image
  8. The Permissions window opens
    Select Property-specific and select Write All Properties.
    Scroll down an add these individual permissions as well:
    – Validated write to DNS host name
    – Validated write to service principal name     
    image
  9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
    image

      Delegation of Control Wizard Summary

    You chose to delegate control of objects
    in the following Active Directory folder:

        saferoad.com/Computers

    The groups, users, or computers to which you
    have given control are:

        Domain Join Account (SvcJoinComputerToDom@saferoad.com)

    They have the following permissions:

        Write All Properties
        Validated write to DNS host name
        Validated write to service principal name

    For the following object types:

        Computer

    The selected principals can now rename a computer in a domain.

4. Allowing a security principal to move computer objects in a domain

    The last one is a little more involved as it requires changing permissions on both the source container/OU and the destination. The destination container/OU requires the same permissions as in scenario 1 so set those. Follow these steps to configure the source container/OU:

    1. Identify the security principal that you want to delegate permissions for
    2. Identify the container or OU where you want to allow users to create and configure computer objects
    3. Right click the container or OU you selected and select Delegate Control…
      image
    4. The Delegation of Control Wizard opens, hit Next
      image
    5. The Users or Groups window opens:
      Select the security principal you want to grant permissions to, then hit Next again.
      image
    6. The Tasks to Delegate window opens:
      Select Create a custom task to delegate and hit Next
      image
    7. The Active Directory Object Type window opens:
      Select Only the following objects in the folder, select Computer objects and , select Delete selected objects in this folders, hit Next 
      image
    8. The Permissions window opens
      Select Property-specific and select Write All Properties. 
      image
    9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
      image

        Delegation of Control Wizard Summary

      You chose to delegate control of objects
      in the following Active Directory folder:

          saferoad.com/Computers

      The groups, users, or computers to which you
      have given control are:

          Domain Join Account (SvcJoinComputerToDom@saferoad.com)

      They have the following permissions:

          Write All Properties

      For the following object types:

          Computer

    More information

    There is an interesting distinction between joining a domain by exercising the user right Add workstation to the domain and using delegated permissions. If you join by the user right the owner of the resulting computer object is the Domain Administrators group, but if you join by delegated permissions the owner is the user who actually performed the join. Also if a principal has both the user right and delegated permissions, delegated permissions take precedent and are used to join the computer to the domain. A recommended best practice her would be to remove all principals from the user right and just rely on permissions. You do that by applying a policy to your domain controllers where no principal has the user right:

    image

    The location of the user right is:

    Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment

    You could also increase the default quota of 10 computer accounts added to the domain per user, but I do not recommend that. I essence you are copying the settings from Windows NT to your Active Directory domain and do not take advanced of the advanced delegation model in Active Directory. For completion here is how to change the quota:

    From any editor capable of displaying and changing individual attributes of Active Directory objects; display the properties of the domain NC. Locate the ms-DS-MachineAccountQuota property and change it to your desired value:

    image

    Links

    Here are a few links for further info:

    SQL Tips for novices

    Before you ask, I definitely count myself as a novice when it comes to SQL. Nevertheless, here are a few SQL tips I have picked up along the way…

    Enable SQL to communicate through the Windows Firewall

    SQL Database
    netsh advfirewall firewall add rule name=SQLPort dir=in protocol=tcp action=allow localport=1433 remoteip=localsubnet profile=DOMAIN
    SQL Browser
    netsh advfirewall firewall add rule name=SQLBrowser dir=in protocol=udp action=allow localport=1434 remoteip=localsubnet profile=DOMAIN
    SQL Server executable
    netsh advfirewall firewall add rule name=”SQLExe(<SQL Instance name>)” dir=in action=allow program= “c:Program FilesMicrosof
    t SQL ServerMSSQL10_50.<SQL Instance name>MSSQLBinnsqlservr.exe” remoteip=localsubnet profile=DOMAIN

    Reference:

    Make the local Administrators group SQL Admin

    It is very useful to have the local Administrators group on a SQL server be SQL Admin. Useful, not necessarily secure or a best practice. To be able to perform these steps you need access to an account that already is an SQL Admin of the server/instance you are trying to change.

    1. Open SQL Server Management Studio and log on
      To use Windows Integrated authentication you need to be logged onto the SQL server computer with an account that is already a SQL Admin, it using SQL authentication; just enter the username and password.
    2. Expand SecurityLogins
    3. Right click and select New Login…
    4. In the Login name field enter BUILTINAdministrators.
      For some reason SQL requires that all built in security principals be prefixed with the word BUILTIN instead of the computername.
    5. Select Server Roles and select serveradmin and sysadmin, leave any existing boxes ticked.
    6. Hit OK
    7. Exit SQL Server Management Studio, log off the computer, log on again with a user that is a member of the local Administrators group and open SQL Server Management Studio again. This time use Windows Authentication.
      Same thing in Transact-SQL:

    CREATE LOGIN “BUILTIN\Administrators” FROM WINDOWS;
    GO

    EXEC master..sp_addsrvrolemember @loginame = N’BUILTIN\Administrators’, @rolename = N’sysadmin’
    GO

    EXEC master..sp_addsrvrolemember @loginame = N’BUILTIN\Administrators’, @rolename = N’serveradmin’
    GO

    If you still cannot get access; make sure you are not running with User Account Control (UAC) enabled. UAC strips the Administrators group from your security token.

    Reference:

    Test connectivity to a SQL Server

    This is pretty cool…

    Create an empty file anywhere in the file system called test.udl.

    PowerShell: New-Item test.udl –type file

    Double click to open it. You will see the following dialogue box:

    image
    Enter the servername, select security mode and database, and hit Test Connection.

    Reference:

    Windows Azure

    Reference:

    Go DBAs! Smile

    Recommendations for LDAP lookup accounts and connections in Active Directory

    Introduction

    From time to time someone may want to access your Active Directory Directory Service with LDAP. Usually from a system or location that you view as unsecure or untrustworthy. Examples are printers that do directory lookups to send scanned documents by e-mail and external systems where a provider needs information about your users to provide them service. The querying party is often an open source implementation of an LDAP client. Here is some advice about how to configure such a setup.

    Connecting

    All Active Directory Domain Controllers provide LDAP over TCP and UDP ports 389, and Secure LDAP (LDAP-S) over TCP port 636, by default. If there is a firewall between your Domain Controller and the connecting system you will have to allow and/or forward the required ports. For any connection you should always use LDAP-S, especially for connections that traverse untrusted networks, e.g. the Internet. For recent versions of Windows Server the host firewall is enabled by default and the inbound rules for LDAP and LDAP-S are automatically enabled when the server is promoted to a domain controller. Depending on your network firewalls you may have to enable Allow edge traversal. You do this from the properties of the rule in the Windows Firewall with Advanced Security console:

    image

    Selecting a DC

    Choosing which DC the LDAP client connects to is either configured by you or located automatically. A Windows machine that is a member of a domain knows how to find LDAP servers in its domain, which it does by querying DNS. A lot of Active Directory discovery is done by DNS in Windows. A Windows client will typically query DNS for A (host) records for its own domain to find which servers are writable LDAP servers. All RW DCs register an A record for the domain name to indicate they are LDAP servers. Alternatively a Windows client can also query for SRV (service) records for _ldap._tcp.dc._msdcs.<DNS domain name>. The DC Locator component, implemented by the NETLOGON service on a Windows machine performs these queries. When a Windows client wants to log on to a domain it uses SRV records. But the fact that a Windows machine that is joined to a domain can find LDAP servers by using DNS does not mean that an application running on it can do the same, or take advantage of the information found by the DC Locator component. Very often an application that uses LDAP implements its own LDAP configuration and service discovery. Typically LDAP servers are either found by querying DNS for either A, CNAME, TXT or SRV records as specified by you, or LDAP servers a statically configured. If the connecting system is on your internal network then the best option would be for it to use DNS to discover LDAP servers based on the DNS name of the domain. That way the system will continue to function even if you introduce new or retire old domain controllers. If that is not possible try using an A record as an alias; like ldap.<DNS domain name>. The you can statically configure your LDAP client to connect to that name. If any change occurs in your directory service, all you have to do is update the alias. You can even have more than one record for the same alias and DNS will serve them up randomly. If the connecting system is outside your network and does not have access to your internal DNS zones, you are left with statically configuring it using either an IP address or an FQDN which is resolvable outside of your network.

    Some more info:

    Certificates

    The domain controller needs a certificate to be able to supply LDAP-S. You can in theory use a certificate signed by any authority, including a self signed one, as long as the connecting party either trust the signer or ignores certificate errors. The following KB article goes into details about the specific LDAP certificate requirements for domain controllers:

    It is not possible to configure a specific certificate for LDAP if there are several to choose from. The aforementioned KB article explains the certificate selection process that the DC uses.

    It is also a good idea to provide the connecting party with a base DN from which to start a search, although you cannot stop them from changing it.

    Account

    After the connection is established the connecting party needs to authenticate to access the directory. The most common form of authentication in this scenario is a username and password combination. Since Active Directory is its own authentication provider you will need to create an account in AD and provide the connecting party with the domain, username and password information. This account will be an implicit member of the Authenticated Users group when it is logged on and thus have the same access rights in the directory as the Authenticated Users principal has. Unless you have changed your directory considerably Authenticated Users will have read access to most of your Active Directory. Changing this is not a trivial task and would require you to change the very basic authorization settings of your directory, and since these settings are enforced on a schedule by the DS you will have to create your own way of making them stay changed.

    Any user account you opt to use will also be a member of the Domain Users group. This grants it certain rights in your domain that you might not want such an account to have. For example a member of Domain Users can log on to computers in your domain by power of the fact that Domain Users is a member of the Users group on every member computer in the domain. I recommend creating a new global security group, called NO_PRIVILEGE for example, and add the account to that group, and at the same time removing the account from Domain Users. By doing this you will revoke any permissions Domain Users has from the account. You cannot just remove it from Domain Users, since every user account in Active Directory must have a primary group associated with it. The NO_PRIVILEGE group will  become that new primary group once Domain Users membership is revoked.

    Testing

    To test if your setup work I recommend an LDAP browser or explorer. Windows includes one called LDP.EXE and it is quite good, but since it cannot ignore certificate errors, it might not work in all scenarios. Here are a couple of alternatives:

    I find that LDAP Admin servers all my needs. It even alerts you to certificate errors and lets you view the certificate and continue if you so choose.

    To test if the required ports are open and forwarded you can also use the PortQry utility from Microsoft. Here is an example command to check for LDAP-S:

    .PortQry.exe –n <my DC FQDN> -p TCP -e 636

    Tip

    To ignore certificate errors in LDAP on open source systems I recommend doing a search for TLS_REQCERT and LDAPTLS_REQCERT.

    Bug in Windows Azure PowerShell module v 0.7.0

    The latest version of the Windows Azure PowerShell module v 0.7.0 (released 21-10-2013), which features such great improvements as Windows Azure Active Directory logon support, unfortunately has a bug relating to endpoint ACLs.

    Any Set-AzureEndpoint or Add-AzureEndpoint command which includes the ACL parameter will seem to succeed, but no ACL changes will be applied to the endpoint. I reverted to the previous release, v 0.6.16.1, and it works correctly.

    I submitted an issue on GitHub, hopefully it will be resolved soon.

    Troubleshooting ISO file sharing in System Center Virtual Machine Manager 2012 SP1

    So I was trying to use sharing of ISO files instead of copying when mounting on virtual machines. The really helpful dialog box in System Center Virtual Machine Manager (SCVMM) 2012 SP1 politely informs you that

    image

    OK, so what configuration?

    I found these steps for VMM 2008: How to Enable Shared ISO Images for Hyper-V Virtual Machines in VMM

    In short this is what you have to do:

    • Use a domain account as the VMM service account
    • Grant share and NTFS Read permissions to the VMM library shares that contain ISO files for both the VMM service account and the computer accounts of any Hyper-V hosts that need to access those ISO files
    • Configure constrained delegation for each Hyper-V host to allow delegation of credentials to the VMM library servers
    • Add the Hyper-V hosts to the Windows Autorization Access builtin group

    If you use a group to grant access to you Hyper-V hosts to the library share, like I did you have to restart them to update their security tokens. Configuring constrained delegation also requires a restart.

    But it wasn’t working! VMM just told med “Update failed” each time I tried to mount an ISO on a VM. This is the error I got:

    Error (12700)
    VMM cannot complete the host operation on the <Hyper-V host> server because of the error: ‘<VM>’ failed to add device ‘Virtual CD/DVD Disk’. (Virtual machine ID <GUID>)

    ‘<VM>’: User Account does not have sufficient privilege to open attachment ‘\<VMM Library server>MSSCVMMLibraryISOs<ISO file>’. Error: ‘General access denied error’ (0x80070005). (Virtual machine ID <GUID>)
    Unknown error (0x8001)

    Recommended Action
    Resolve the host issue and then try the operation again.

    The Internet didn’t know why it didn’t work either. I know because I asked it!

    As far as I cloud see my permissions were correct so I had to figure out if there was another account involved. The best way I know to do that is by auditing object access. So first I enabled auditing of object access on my VMM Library server:

    image

    Next, to catch all security principals trying to access the files in the VMM Library, I added audit System Access Control List entries for both Authenticated Users and Everyone:

    image

    After setting this up I tried mounting the ISO again and then opened the Security Event Log. The first event of interest was a logon event (Event ID 4624):

    image

    The account listed here is the Run As account I use for Hyper-V host management. This was an Audit Success event since the account was allowed to log on to the VMM library server.

    Next was an attempt to access a share (Event ID 5140):

    image

    Again it was the RunAs account this time trying to access the VMM Library share with read permissions (ReadData or ListDirectory). Again, this was an Audit Success event since this was just a request for access. This was followed by something called a detailed file share (Event ID 5145):

    image

    This was our first Audit Failure event. This event is the result of the File Share request in the previous event. As you can see it was not successful. For the user this will result in an access denied message; exactly what I was seeing in the VMM console.

    So apparently the RunAs account is also involved in accessing the share. To test to see if this was the solution I added the RunAs account to the share and NTFS permissions with Read access. Immediately it was successful and the VM could access the ISO file directly from the VMM Library.

    Happy that I made it work I was still interested in knowing why the RunAs account was used for this. The answer was to be found in the VMM Add Resource Wizard. This is the wizard used to add fabric resources to VMM, like Hyper-V hosts or clusters. On the Credentials page we see this:

    image

    So the RunAs account is stored and used to access the hosts discovered with the wizard. The universe was once again in balance.

    Listing Windows Azure availability sets

    Windows Azure guarantees a 99.95 % uptime SLA, but this is only for multiple instance roles. So, for example, one web server by itself will not be guaranteed 99.95 % uptime, but will rather have “best effort”. Whereas two, or more, in a multi instance role will. So how do you make something multi-instance?

    You use something called an availability set. An availability set is spanned across multiple fault and update domains in the datacenter. A fault domain is a collection of resources that are expected to fail together, like a server rack. An update domain is a set of resources that are updated at the same time. An availability set ensures that your instances are spanned across multiple update and fault domains so that no single failure or update can impact all the instances. The point here is that all the instances must be the same and be able to offer the same service to your users. So going back to our example with web servers you have to have at least two identical ones in the same availability set for your service to have a 99.95 % uptime guarantee. It is not correct to say that any VM or instance is guaranteed 99.95 % since it is the service that the instance offers that is guaranteed. Furthermore only Internet facing services have the SLA, since you need to use the Windows Azure load balancer to publish your instances, but more on that another day. Back to availability sets.

    You add VMs to availability sets either in the Windows Azure portal, with PowerShell or the REST API. In the portal or PowerShell there is no way to explicitly create an availability set, you always create one as a side effect of configuring a VM. In the portal it looks like this:

    image

    This is an availability set with only one instance. In the drop down list I can either remove the VM from the availability set or create a new availability set and add the VM to that set.

    Note: when you either add or remove a VM from an availability set, it will get a new NIC. This will have the same IP address as before but you will see that its number has been incremented.

    In PowerShell you use the Set-AzureAvailabilitySet or New-AzureVMConfig cmdlets. Set-AzureAvailabilitySet updates an existing VM while New-AzureVMConfig lets you specify an availability set when you create the VM.

    Something I miss is the ability to list all my availability sets. Since there is no (yet) Get-AzureAvailabilitySet cmdlet you have to extract this information from each of your VMs. Here is a quick one-liner to do that:

    https://gist.github.com/morgansimonsen/8039845

    This will list the VM names, cloud service names and availability set names (if any) for all your VMs. Feel free to add any kind of formatting or sorting to the output.

    Introducing BUSCON

    I am often asked, usually on some form of IM media; “are you busy?”. I often find this question hard to answer since I regard busy-ness (is that a real English word?) as more of a state with varying degrees. This has led me to the definition of BUSCON or BUSy CONdition, based on the well-known DEFCON or defense readiness condition used by the United States Armed Forces. At the current time BUSCON is defined like this:

    Busy condition Busy-ness Color
    BUSCON 1 Metaphysically busy (AKA “Leave-me-the-fuck-alone” busy)* White
    BUSCON 2 Extremely busy Red
    BUSCON 3 Really busy Yellow
    BUSCON 4 Above normal busy-ness Green
    BUSCON 5 Normal busy-ness Blue

    As BUSCONs creator I reserve the right to change its definition at any time. Check back here for updates if you find the BUSCON definition useful.

    * So you take offense by my use of profanity in this post? Here are a couple of quotes that sum up my views on that area:

    Stephen Fry: “It’s now very common to hear people say “I’m rather offended by that”, as if that gives them certain rights. It’s actually no more than a whine. “I find that offensive”. It has no meaning, it has no purpose, it has no reason to be respected as a phrase. “I’m offended by that”, well so fucking what.” **

    Salman Rushdie: “What is freedom of expression? Without the freedom to offend, it ceases to exist.”

    ** See first asterisk