Slides from our webinar How to create awesome customer experiences are now on SlideShare. Get them here.
Over the years the setup process for the Windows OS has been streamlined and optimized a lot. It used to be that you have to input a lot of information throughout the installation and the actual transferring of the OS files onto the hard drive took a long time. Now, the data copying has become a lot quicker by using things like imaging technology, and the user interaction during setup has been reduced to the bare necessities. So much so in fact, that I personally am now missing a few options that I could previously set. One of those is the computer name or hostname; the name you give your computer. In Windows 10 there is no question during setup what the computer should be called. Instead, Windows Setup automatically generates a name for you that looks something like this: DESKTOP-7KCPLCO. You can of course change this later using e.g. PowerShell’s Rename-Computer cmdlet. The problem is that the original name is often stored in the services you connect to, before you can actually change it. For example, when you join Azure AD during the Windows 10 Out-of-Box-Experience (OOBE), your machine is joined to Azure AD with the name that Windows Setup configured, and even if you change it later, it does not update in Azure AD. This is surely (hopefully) something that Microsoft will fix, so that it works the way it does in local Active Directory, where, if you change the name of a domain joined computer; the name in the directory also changes. But for now, that is not the case, and it can be quite a challenge keeping track of all those DESKTOP-<random number> machines.
Luckily there is a workaround available. (In fact, there might be more than one workaround, but one was enough for me.) The one I made work was using the Windows unattended install support to supply a computer name during the specialize phase of Windows Setup. I basically configured an XML file that told Windows Setup which name to give the computer. Since there is no GUI prompt for this it all happens behind the scenes during your install. Using unattended setup of Windows is usually something that is only cost effective if you are going to install a bunch of machine over a long period of time, and it usually requires a lot of configuring a testing and things like driver packages, reference machines, distribution shares and in-depth knowledge of the Windows DISM utility. But in our case we need none of that, the only thing we want is a file with the name of the computer in it. This is how you set that up…
The file that holds all the information to install Windows 10 in a highly customized, hands-off fashion is called an answer file and is called unattend.xml by default. It is usually generated with the System Image Manager tool, which is part of the Windows Assessment and Deployment Toolkit (ADK). Hundreds of settings can be added to unattend.xml, but right now we only need the one for the name of the computer. This particular value is called ComputerName and is configured during the specialize phase of setup. Here is the entire chunk of XML you need to set the name of your computer using unattend.xml:
<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="specialize"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>ENTER YOUR DESIRED NAME HERE</ComputerName> </component> </settings> </unattend>
You must enter you desired name in the ComputerName element, and also change processorArchitecture from amd64 to x86 if you are using this file to install the 32-bit version of Windows (which you shouldn’t). Remember to adhere to the rules for computer names, which you can find in the information about the ComputerName element provided above.
You need a removable drive
So how do we get Windows Setup to read our unattend.xml file during setup? When we do large deployments of Windows we usually have several XML files for different variations of installs, and they are specified using the deployment tools used. Luckily for us, we need nothing so complex here. Remember, we are talking about the occasional install of a few machines. Windows Setup is configured to implicitly look for an unattend.xml file in several locations when it starts. (It’s called implicit, because you can also explicitly provide an answer file using a command line parameter.) Windows Setup looks in a lot of places for unattend.xml, and also looks for other XML files to use with other phases of setup, but we don’t need to go into detail about that here. Setup will look for unattend.xml in the root of all RW/RO removable drives on the system, and this is by far the easiest method to achieve what we are trying to do here.
After you have configured your desired name in the piece of XML provided about, save it as unattend.xml, in the root of either the USB drive from which you are installing Windows, in the root of another USB drive, of even on a floppy disk (virtual or physical). As long as it is called unattend.xml, is in the root of the drive and the drive is of type removable, it will be picked up by Windows Setup. Start Windows setup as you normally would and wait until OOBE starts, then configure your computer like you want it. The setup process itself will not change and you will have no indication that the machine has been given another name until you can access the desktop and check for yourself. Once that happens you can use e.g. hostname.exe to see if your change was successful.
Note that since setup looks in several places for unattend.xml, it might find more than one. There is a search order and the answer file with the highest precedent is used. Make sure you know which one will be picked in your scenario and that you make your changes in that file.
BTW: I hope someone out there picked up on my attempt at Shakespeare-pun in the title of this post:
“A rose by any other name would smell as sweet”
-Juliet in Act II, Scene II of Rome and Juliet
Ever since the Windows Subsystem for Linux/Bash on Ubuntu on Windows feature in Windows 10 I have been playing around with it. Canonical, the makers of the Ubuntu Linux distribution, and Microsoft, made the Windows Subsystem for Linux (WSL) together, and it enables bash, which is the de facto default CLI shell on Linux, to run on Windows as a first class citizen. You no longer need things like Cygwin to run bash and its command language and tools on your Windows 10 computer.Recently I did a little customizing to get a more genuine Ubuntu feeling on my Windows box. Specifically I wanted to make my Windows-based bash window look as much as the real thing as possible.
Windows has its own fonts for console windows, like Command Prompt (Consolas) and PowerShell (Lucida Console). But Ubuntu uses the Ubuntu Mono font for its console windows. Luckily for us the Ubuntu Font Family, of which Ubuntu Mono is a member, is freely available to anyone, in easy to install TTF format. To use it for your bash windows, download the package from the Ubuntu font site, extract its content and right-click each font file (.ttf) you want to install.
Now, open your bash shell and edit its properties. In the Font list, select the newly installed Ubuntu Mono font:
Granted, it’s not a huge difference between the default font and Ubuntu Mono, but the devil is in the details 🙂
You would expect that a service that is responsible for the naming of objects within a namespace should prohibit the creation of objects with the same leaf name and fully qualified name. Put simply you should not be able to have two files in the same directory with the exact same name in your file system. Likewise a directory service should do the same, or should it…?
It depends on the rules of the service actually, and what those rules specify must be unique. Take good old Windows Server Active Directory for example. Active Directory is based on LDAP and in the LDAP naming scheme an object may have the same Relative Distinguished Name (RDN), as long as the Distinguished Name (DN) is unique. In this case the RDN is the leaf name and the DN is the fully qualified name. So you can have two users named John Doe as long as they do not both reside within the same Organizational Unit (OU), or location, in the directory. So in AD the rules specify that the DN must be unique. There are also other rules like the ones that say no two users can have the same sAMAccountName or UserPrincipalName properties.
Azure Active Directory also has similar rules, for example you can’t create two AAD users with the same UPN (but they can have the same name). Azure AD groups act differently however. First of all they don’t have UPNs, they only have names (DisplayName attribute). So for groups the rules say that it is the ObjectID property of the group that must be unique, not the name. You can test this yourself easily with PowerShell. Run this command against your AAD tenant twice or more:
New-MsolGroup -DisplayName "GroupWithTheSameName"
It will succeed and you are left with a number of groups which look identical until you look at their ObjectID properties. I’m sure you can imagine the interesting side-effects of having more than one group with the same name… How is this allowed you ask?
The answer is hybrid identity. Azure AD and it’s local sync component; Azure AD Connect, supports syncing users and groups from multi-domain forests and multiple disparate forests into the same Azure AD tenant. This is great for consolidation scenarios, but to understand exactly how it relates to duplicate group names in Azure AD; let’s look at the rules for uniqueness in Active Directory again:
- Single forest
- Users must have a unique UPN attribute within a forest, and a unique sAMAccountName attribute within the domain. No such requirement exists between forests. The RND can be the same as long as the DN is unique.
- Groups must have unique sAMAccountName attributes within a domain. No such requirement exists between forests. The RND can be the same as long as the DN is unique.
The mechanism within a forest that makes sure the above requirements are met is the global catalog (GC).
- Multi forest
- Anything goes, nothing is shared between forests, even forests that trust each other. You could even have two forests with the same forest root name and UPN suffixes. There would not be able to interact with each other of course.
Form this we see that we can have groups that have the same name, they are only separated by their sAMAccountName attributes in Active Directory. Azure AD Connect does not synchronize the sAMAccountName into Azure AD so we get duplicate groups.
At this point you may be wondering what happens if you have two disparate forests with the same forest root name, how will they sync? Answer is they won’t, that is not a supported scenario by Azure AD Connect, which uses DNS to find the DCs of the forests.
You may also be wondering why this does not apply to users. Users have a unique attribute that is synced into Azure AD; the UPN. As long as it is unique within the forest the user will sync to Azure AD. If you have two forests with the same UPN for two or more users, but still are able to be part of the same Azure AD Connect sync installation, something which is possible if you configure the same UPN suffix in both forests, Azure AD connect will block the syncing when it encounters these users.
NOTE: Manipulating Active Directory directly it is actually possible to have two users with the same UPN in the same domain or forest. If you try to sync those users into Azure AD they will be blocked like described above.
The good news regarding groups is that Microsoft are working on a way to handle groups better in Azure AD Connect so that we do not get these duplicates.
Always fun with a little directory service internals 🙂
The fine people at Cisco Meraki have recently enabled SAML SSO support to their Meraki Dashboard service. For those of you who don’t know Meraki is Cisco’s cloud managed networking solution. Basically you manage all your networking equipment from a web portal. For more information about Meraki, go here.
Whenever I start using a new web application, which is what the Meraki Dashboard is, I always look for options to integrate it with my existing identity platform, which in my case is Azure AD. The benefits of doing this should be apparent and are not in the scope of this post, but basically I want to control access to all applications with one identity and thus limit the numbers of logons I have to maintain.
Note: Let me just mention that at the time of writing; the SAML SSO feature of the Meraki Dashboard is in Beta.
So let’s look at how we can now integrate Azure AD and Meraki.
Meraki have provided their own documentation on how to set up SAML SSO with either ADFS or OneLogin, this documentation is available here. But we want to use Azure AD.
In this section we complete the basic SSO setup.
- First enable SAML SSO for your organization. Just enable it for now and press Save.
- Go to the Azure portal and add a new application to your Azure AD tenant. Select to add an application from the gallery and then select Custom. Name your application something like Meraki Dashboard:
- On the page of your newly created application select Configure single sign-on.
- Select Microsoft Azure AD Single Sign-On as the sign on method.
- For your application identifier and reply URL enter https://dashboard.meraki.com.
NOTE: We will change the value of the Reply URL in the following steps.
- Download the certificate in Base 64 format and open it.
- On the Details tab, find the certificate thumbprint and copy it.
- Go back to the Meraki Dashboard and paste the thumbprint value into the X.509 cert SHA1 fingerprint field. You must replace all spaces with colons. Hit Save. You should now have a Consume URL displayed, it will look something like this:
https://n150.meraki.com/saml/login/<unique ID>. Copy this value, we need it later. Enter the URL of the Azure AD MyApps portal in the SLO logout URL field. Your complete configuration should now look something like this:
The logout URL is where the Meraki Dashboard will redirect users when they sign out, this location should be where they can sign in again, which in this case is the MyApps portal.
- Go back to the Azure AD portal and go back one step in the Configure Single Sign-On wizard to enter this value into the Reply URL box. Reply URL is also known as Assertion Consumer Service (ACS) and is where the application expects the authentication response from the IdP. Your final settings should look like this:
- Advance to the page of the wizard where you downloaded the certificate and check the box labelled Confirm that you have configured single sign-on as described above. Checking this will enable the current certificate to start working for this application.
- Finish the Configure Single Sign-On wizard.
Configure SAML Roles in your Meraki organization
Now we need to configure roles in Meraki Dashboard to control the level of access that SSO users get. You can configure many roles and granular network access here, but we will create only one role.
- Go to the Meraki Dashboard and navigate tot Organization\Administrators.
- Find the SAML administrator roles section and select Add SAML role
- Name the new role Organization and set organization access to full, do not select any target networks:
In this section we configure the claims that the Meraki Dashboard needs to work. Currently Meraki Dashboard requires a username and a role claim, issued using their naming standard.
- In the Azure AD portal, go to the Attributes tab of the Meraki Dashboard application.
- Add the following attributes:
Attribute name: https://dashboard.meraki.com/saml/attributes/username
Attribute value: user.userprincipalname
Type: User attribute
Attribute name: https://dashboard.meraki.com/saml/attributes/role
Attribute value: Organization
Feel free to delete any claims you don’t want to send to the Meraki Dashboard.
Configure Access to the Meraki Dashboard application
In this scenario we use Azure AD as the control plane for who gets the Organization role we specified earlier. We do this by assigning the Meraki Dashboard application to the specific users we want to be organization admins.
- In the Azure AD portal select the Users and Access tab of the Meraki Dashboard application
- Select Show: All Users in the drop down box.
- Select the users you want to be organization admins and hit Assign at the bottom of the page.
About Roles in this setup
As you can see from the above configuration, all users that are assigned the Meraki Dashboard application will get full Organization access, based on the role we created This is almost certainly not what you want, but this is just an example. In the Meraki guide for ADFS we see that they use Active Directory groups to select which role is passed in the claim. Unfortunately, the logic to do this is not available in Azure AD at the moment. You cannot select a claim value based on a group. What you can do instead is use a free attribute in either your local Active Directory or Azure AD to specify the name of the Meraki role to give the user. To accomplish this you must first map out all the Meraki roles you need and then provide the names of these roles in the role claim, based on the value of the attribute.
Now let’s see if it worked.
- Log in to the Azure AD MyApps portal as one of the users that you assigned to the Meraki Dashboard application; https://myapps.microsoft.com.
- Meraki Dashboard show now show up as an available application:
- Hit the icon and you should now be forwarded to the Meraki Dashboard.
- Notice that your username at the top is now your User Principal Name from Azure AD.
- Navigate to Organization\Administrators and hit SAML login history. This will display all SAML logins to the dashboard. Your login should show up here. You can also press the value in the timestamp and you will see more details, and you can even view the entire XML assertion.
Hopefully everything is working for you. If you want to further customize this setup you could for example add a logo to your app and remove the claims not needed by the Dashboard. You now also have access to all the advanced access policies of Azure AD and can add MFA and location based access rules and provide delegated self-service access.
Notes about the setup
There are a few things to note about the Meraki SSO support in general and this setup in particular.
- Meraki Dashboard currently only supports Identity Provider (IdP) initiated sign-on. This means you have to start in the Azure MyApps portal, log in, and then proceed to the Meraki Dashboard by pressing the icon. Going to the dashboard first and trying to log in with an ID from Azure AD (or any IdP) will not work. This last scenario is what is known as Service Provider Initiated sign-on (SPinit). (I’m thinking you should be able to create a smart URL here, but have not have time to test that yet.)
- If the username of the admin that signs in with SSO is already registered as a regular dashboard admin the sign in will fail.
- There is already a pre canned Cisco Meraki Dashboard app in the Azure AD application gallery, but this only supports password SSO, which means that you will have to enter your regular Dashboard account login details into the Azure AD credentials vault and then have Azure AD forward those credentials when users sign in. This is not true SSO. However, I recommend you harvest the icons from this app and use in the one you create. (The URL of the logo is: https://az495088.vo.msecnd.net/app-logo/merakidashboard_215.png)
For more information on Meraki Dashboard permissions and administrator types, refer to the article on managing administrative users
I spend my time working with public cloud services for a large number of organizations. That means many, many different user accounts to keep track of. The tool I use most to interact with these services is the web browser. As you all know browsers try to make life easy for their users, and therefore they cache a lot of information, including logins, cookies and AuthN tokens (these are cookies too). All in an effort to make it easy for an end user to get to his stuff quickly. But we are not end users are we…? For me all this caching is very inconvenient when I need to be someone other than my own identities, which is all the time. And not only that but at the same time that i want to operate as myself. Here is how I have this set up today.
For me Google Chrome works best. It has the features I need, simple as that. My reasons are laid out below.
Securing Login Information
I keep all my login information secure in a KeePass 2 database. I choose KeePass 2 because it has good encryption (AES-256), great multi-platform support, lots of plugins, good security features like automatic workspace lock, is open-source and free. I keep my KeePass databases in a cloud storage account protected with Multi-Factor Authentication (MFA). KeePass lets me generate long, complex passwords easily so I never (ever) reuse passwords anywhere.
Accessing Login Information Easily
I mentioned that KeePass has great plugin support. One of my favorite plugins is KeePassHttp, which exposes password entries securely over HTTP. It creates a local HTTP endpoint that authorized clients can talk to. Authorization is controlled in KeePass and is thus protected by the KeePass master password and any other factors you may have chosen.
KeePassHttp together with the Chrome extension chromePass completes this setup by serving up the necessary login information based on URL. chromePass connects to KeePassHttp and retrieves the login information from the KeePass database that matches the URL of the site you are visiting. If several entries match you get a list to choose from. By default KeePass will not just serve up the login information, you have to approve it from a prompt displayed by KeePass.
Multiple Personalities – in a good way
The final piece of the puzzle is the Chrome plugin MultiLogin. It takes care of the problem of the browser trying to cache your login information and state in cookies. Whenever you hit the MultiLogin button Chrome starts a completely clean browser tab that is not related in any way to what is going on in any other tabs. Each new MultiLogin tab is identified by a number so you can easily tell them apart. All tabs with the same identifier share the same state, so you can have several tabs where you are the same user. Everything in the MultiLogin tabs is destroyed when you close Chrome so nothing will be remembered.
I use regular Chrome tabs for my own private web surfing, and Chrome caches my logins and stores cookies just like normal. For everything else I use MultiLogin tabs. This also has the added security benefit of never storing any session or AuthN cookies when you close Chrome.
Unfortunately the developer has removed MultiLogin from the Chrome Store for unknown reasons, and I have not been able to find a replacement. I was lucky enough to install it when it was available, so thanks to Chrome’s roaming extension feature I get it on all my computers. If you still want to get MultiLogin there are instructions here for installing it manually.
UPDATE 27.10.2016: A new Chrome extension called openMultiLogin has been released that replicates the functionality of MultiLogin. Check it out in the Chome extensions store.
This is slightly off topic for me, but because I spent quite a bit of time on figuring it out and could not find this documented anywhere else, I thought I would write it up quickly.
At some point I could no longer install any new apps from the Windows Store on my Surface 3 Pro Windows 10 machine. Apps already installed would update fine, but new ones could not be added. The error was:
“Try that again. Something went wrong. The error code is 0x8007001, in case you need it”.
If we translate that number to a human readable form we get:
Not much to go on. I initially thought this was something to do with either the modern app framework or Windows installation and tried things like resetting the store with (WSReset.exe) and scanning the system files with SFC.EXE. None of these things helped. In the end it turned out that is was related to my SD card. I had an SD card installed and had previously moved a few apps to it. Apps that were so large that I didn’t want them eating up my system drive. Moving these apps somehow caused all new apps from then on to try to install on the SD card, or at least rely on it for something during the install. I shut down the computer, removed the card and could then install apps again. At this point I also reinserted the card and could now also install new apps with the card inserted. Some setting somewhere had obviously been changed. I do not know the root cause of this behavior, which is always annoying, but I am prepared to accept that I made it work.
Updating already installed apps worked because they were all on the correct (C:) drive. The default install location for apps was also set to the C: drive, which makes this even stranger…
Hope this helps someone. Happy installing!
Microsoft is working on creating a unified OneDrive Windows sync client for both consume OneDrive and OneDrive for Business. This is very good news and you can read all about it here.
But the download links on the Office support pages are not for the latest version of the Next Generation Sync client (ODNGSC). At the time of this writing the latest version is 17.3.6349.0306, but the download link is for 17.3.6302.0225. So why does this matter? The ODNGSC updates itself as part of an Office 2016 update cycle or individually. When you deploy the client you might have some issues that are blocking you, stopping you from completing setup. If that is the case the client cannot update itself, because initial setup has not been completed. So you can’t get the version that might fix your setup problem. Catch 22.
Right now, one such problem is trying to use ODNGSC in Azure RemoteApp (ARA) images. In ARA users’ profiles are redirected to profile disks (VHDs) stored in Azure storage accounts. The redirection happens by using a reparse point linking the VHD to the user’s %USERPROFILE% path. The ODNGSC will not accept a path that includes a reparse point so you cannot install the client. If this error was fixed in a more recent release than the one currently installed or available for download, you would face the above problem. (So right now, this trick does not help you, but it serves to explain why I wanted to get to the latest client binaries.)
To work around this and perform initial setup with the latest ODNGSC, do this:
On a machine that has the latest version, navigate to:
In that folder you will find the setup file (OneDriveSetup.exe) for the latest client. If you look in the Update.xml file in the same directory you will also find the URL of where that client was downloaded, something like https://oneclient.sfx.ms/Win/Team/17.3.6349.0306/OneDriveSetup.exe.
I just applied for e-Residency in Estonia!
As an e-Resident you are issued a secure digital identity by the government of Estonia. This enables you to use services provided by the Estonian state agencies and private sector. Thing you can do:
- Establish a company online
Estonian companies can be established, registered, and administered entirely online.
- Open a bank account in Estonia
Estonia is well-known for its user-friendly and secure online banking. The e-Resident smart ID card is approved by LHV, Swedbank and SEB banks in Estonia, with others planned in future.
- Digitally sign documents and contracts
Digital signatures have been available in Estonia since 2000 and are used daily. More than 200 million digital signatures have been created in Estonia since inception.
As someone interested in digital identities I think this is fantastic stuff, and heralds the coming of a new age of business. Looking forward to visiting the Estonian consulate in Oslo to pick up my ID card.
Read more about Estonian e-resicency here:
I was helping a customer set up a hybrid Exchange environment recently. When the time came to run the Office 365 Hybrid Configuration Wizard we received this error:
The error given is:
The UTC time represented when the offset is applied must be between year 0 and 10,000.
Parameter name: offset
I asked the Internet and quickly discovered that this is not a Hybrid Configuration issue, but rather some bug in the .NET framework DateTime function. I soon found this page (quite old as you can see). To quote the author: The value of DateTime.MinValue cannot be cast to a DateTimeOffset if you are east of London!
So the solution in our case was to temporarily set the time zone of the server where we ran the Hybrid Configuration Wizard to UTC (Coordinated Universal Time), aka. GMT.