To achieve this goal, we added a few domain controllers to Azure, so that ADFS/DirSync would still be able to find a DC even if our on-prem DCs were unreachable. So far so good.

However, we’ve been having lots and lots of ad replication issues between our on-prem DCs and our Azure DCs. Replication between our main site and our back-up site have always been flawless so I kinda suspected it wasn’t related to the DCs in our main site.

Digging deeper into this, I found the following:

1. Our errors seemed to be RPC-related (lots of these: “Active Directory Domain Services attempted to perform a remote procedure call (RPC) to the following server.  The call timed out and was cancelled”)

2. PortQuery show no problems hooking on to LDAP, and RPCPing between DCs was happy as well

3. This is the best article around, for troubleshooting AD replication related to RPC: http://social.technet.microsoft.com/wiki/contents/articles/4494.troubleshooting-the-rpc-server-is-unavailable.aspx

4. Using Wireshark, I noticed we were getting a high number of retransmissions when AD Replication was attempted.

5. Our Azure VPN link is terminated by a Juniper SSG140 on our side, and the VPN setup was kinda done manually, since our on-prem network is quite “strange”. After hours and hours of fiddling, we decided to uncheck these guys (Optimized/Rekey):

6. So far, our replication is a lot more stable now. I’ll wait and see….

It’s worth noting that once we figured out that the errors were not related to our on-prem DCs we spun up a test domain seperate from our production domain, with on on-prem DC and one Azure-based DC. Seing similar problems in this domain led us to believe that this was network-related. Having a test-environment also let us do crazy stuff like isntalling WireShark on our DCs – something I would not recommend doing in production.

Cloud is happy again!

As it turns out, us IT Pros or whatever we call ourselves have a lot to learn from our developer friends (or foes, depending on your experiences). Take that huge library of PowerShell scripts you have in your documents library, for instance. Developers figured out that they needed source control for all their code decades ago, while we’re nowhere near.

The reason for that is quite simple. Working in code is fairly new to us admins. With the exception of router configuration, there was simply no way to “pack” what we do into code. The “artifacts” we produced and updated were install procedures and binders with runbooks in them. And screenshots. Lots and lots of screenshots to document the way we clicked through wizards. Not so much anymore.

With PowerShell now becoming a first-rate citizen this is all changing. The whole notion of “Infrastructure as Code”, which is a lot older in the *nix community than among us Windows folks is finally becoming real-world. And if you don’t know PowerShell yet, you better hurry up!

So, now that our “work” can be encapsulated in ps1 files instead of word documents, it’s time to have a look at what developers are doing and see if there’s stuff we can pick up. Source control is one. Git is a bit of a mouthful to many, but there are several tools you can use to make the whole git “experience” a lot more enjoyable. SourceTree is a great example of a well-working client that “talks” git but hides all the weird commands from you. Unless you really want to see what’s going on, that is.

Another area where we have lots to learn is around testing and so-called continous integration (CI). In a development project, chances are the first thing that’s done is to set up a CI server to do continous integration. It works like this: Developers code away, and when they’re happy with a component or class or whatever, they check it in (upload it, so to speak). The CI process then kicks in and compiles the project (with the new changes) and run so-called “unit tests” (the tests are defined along with the code itself). Unit tests are small programs that make sure that a function that mutliplies two numbers actually is able to multiply those numbers – for instance. If the unit tests are all green, then the CI server spits out a new “build” of the project.

Some take this CI notion even further, and implement systems for “continous deployment” or continous delivery. These systems wait for new builds from the CI Server and deploys (installs or upgrades) the program into various environments (test, staging, production). Imagine a team for developers working on a web site. Code is changed and committed, and the systems automaticly compiles, builds and deploys the changes to a test environment. When everyone’s happy with the results, the change is deployed into production with the push of a button and the new “version” is live for me and you to use.

So, back to the quiestion: What can we IT Pros learn from or dev friends?

As it turns out, lots if what we do can’t be directly translated into developer processes. An administrator’s world revolves around controlling change, and while a developer can materialize her changes in the form of a “build”, that’s not so easy for an administrator. We can’t “build” our entire datacenter everytime we change an IP address or a policy our a router config.

However, some processes are very developer-y. One such process is OS Deployment. There is development (scripts are changed), which results in a build (an image), which is tested (in a virtual environment or a test computer) and then deployed into production (installed onto user’s laptops or workstations).

So, with that in mind I wanted to try and implement a OS Deploy process using Microsoft MDT and Jetbrains Teamcity, which is a popular CI Server. More to come!

So, I wanted to find out how little code could be used to successfully create a VM based on a template. First stop: PowerShell ISE.

If you have the VMM console installed on the same machine as your ISE, you can simply load the VirtualMachineManager modules in the ISE console to have a look at them:

Get-Module -ListAvailable Virtualmach* | Import-Module

From there, you can view the CmdLets in the built-in help. You need to hit “Refresh” first:

These “tabs”, like “NewStoredVmFromHardwareProfile” are so-called parameter sets. They are used in CmdLets to make sure that you pass the required parameters to that CmdLet. For instance, if you pass parameter “foo”, you also need to pass parameter “bar”. On the other hand, if you pass parameter “flunk” then that’s all you need. So, these parameter sets represent groups of parameters that you can pass the CmdLet. More on Parameter Sets can be found here.

Anyway, looking at the one called NewVmFromVmConfig seems to be the “cheapest” one to use, it only requires two parameters (the ones with a star):

This is also the one used in the script VMM spits out when you hit the “View Script” button. The “Name” parameter should be fairly straight forward. The “VMConfiguration” parameter less so. VMConfiguration basically represents the config of the VM you wish to create (duh), and you can create it from a VM Template.

If you have a template with everything in it (run as accounts, join domain details, product keys and what not), the VMConfiguration part is simple. So, from the 57 lines og ugliness of the generated VMM script, I ended up with a function which is really only 6 lines of code. Mind you, this will only work if your template is already configured with all the settings VMM expects to find to be able to fire up your new VM.

Here’s the function I ended up with:

Function Deploy-SCVMSimple
    {
        [CmdletBinding()]
        Param(
            [String]$VMName,
            [String]$cloud,
            [String]$Template
            )

        $TemplateObj = Get-SCVMTemplate -All | where { $_.Name -eq $Template }
        $virtualMachineConfiguration = New-SCVMConfiguration -VMTemplate $TemplateObj -Name $VMName
        $cloudObj = Get-SCCloud -Name $cloud

        Write-Verbose "Creating VM $VMName in cloud $cloud"
        New-SCVirtualMachine -Name $VMName -VMConfiguration $virtualMachineConfiguration -Cloud $cloudObj -Computername $VMName| out-null

        #return object
        Get-SCVirtualMachine -name $VMName
    }

And you can run it like this:

Deploy-SCVMSimple -VMName "TestComputer9" -cloud "VDI Computers" -Template "VDI Template V2" -Verbose

Quite a nice improvement!
Oh, by the way: This script does not do any validation of the parameters you pass it, so expect bad things to happen if you start using this in production as-is. It is only meant as an excercise.

The team has done a tremendous job of exposing the various config tasks in Server Manager. Tasks such as changing SSL certs across multiple hosts or deploying new VDI collections use remoting and PowerShell workflows to an impressive degree. It all seems almost too easy. Which is just what it is when you get stuck. Microsoft has completely forgotten to write good documentation for its VDI implementation. All you’ll find on Technet is some “test lab guides” (that are more often than not wrong of simply missing important steps) and a “troubleshooting” guide. I mean, come on. The best I’ve found so far is the built-in help for the RemoteDesktop PowerShell module. Simply nowhere near good enough for serious use.

Anyways. Apart from a few glaring bugs, the solution works fairly well. User Profile Disks are nice, and it’s even possible to specify what parts of the profile to keep at logoff, and what to discard.

The bugs I’ve found:

1. When creating a new Collection (of VDI VMs), I’m not able to choose the Template VM (or “Gold VM”) from the list. It simply isn’t there. Using PowerShell to create the Collection, it all works as advertised

2. If you’re customizing the VMs with an unattend.xml file, I’ve read that you need to remove the first line in the unattend file, or else the deployment will fail.

3. The “Auto save delay” setting on the collection, which specifies how long the VM should be kept running after user logoff before reverting, doesn’t always work. I have no idea why.

As for the PowerShell support, it’s in line with the rest of Windows Server 2012 – just great. It lets you script every single thing you’re able to do in the UI. Some of the CmdLets take an insane number of parameters, but that’s just how it is. Lots to do. In case you need it, I’ve included my own script for deploying a new Collection of 3 VMs. The “Template VM” needs to be a sysprepped VM, in powered off mode. I’ve tried to explain the various parameters as best I could, since official documentation is so lacking at the moment.

$CollectionName = "Timpex VDI" #Name of the VDI Collection
$TemplateName = "Timpex_VDI_Template" #The VM to be used as a template. Needs to be sysprepped and shut down
$TemplateHostServer = "TP-HV01.timpex.net" #The Hyper-V Server where the template exists
$Allocation = @{"TP-HV01.timpex.net"=3} #The hosts and number of VMs to create. Here I'm creating only one, on host TP-HV01
$usergroups = "TIMPEXNET\domain users" #The AD Group with access to the Collection
$ConnectionBroker = "tp-app13.timpex.net" #The Connection Broker computer
$UnattendFilePath = "\\tp-app13\c$\RDVirtualDesktopTemplate\Timpex-vdi-template-unattend.xml" #Path of the unattend file (Be sure to remove the first line (<!--?xml version="1.0" encoding="utf-8"?-->) in this file.
$LocalStoragePath = "D:\Hyper-V Data\VDI" #Where (on the hyper-v host) the VMs should be placed
$NamePrefix = "TPVDI" #The computername prefix of VMs. A number will be added to this prefix when VMs are generated
$UserProfileDiskPath = "\\tp-fil01.timpex.net\uvhd" #Path of User Profile disks
$machineOU = "OU=VDI VMs,OU=Workstations,DC=timpex,DC=net" #OU where machine accounts for VMs are to be placed. The connection broker computer needs write access to this OU.

#Do it
New-RDVirtualDesktopCollection -CollectionName $CollectionName -PooledManaged -VirtualDesktopTemplateName $TemplateName -VirtualDesktopTemplateHostServer $TemplateHostServer -VirtualDesktopAllocation $Allocation -StorageType LocalStorage -Description "PowerShell created Virtual Desktop Pool" -UserGroups $usergroups -ConnectionBroker $ConnectionBroker -VirtualDesktopNamePrefix $NamePrefix -VirtualDesktopPasswordAge 31 -UserProfileDiskPath $UserProfileDiskPath -MaxUserProfileDiskSizeGB 10 -OU $MachineOU -LocalStoragePath $LocalStoragePath -Verbose -CustomSysprepUnattendFilePath $UnattendFilePath

#Configure stuff
$RDColl = Get-RDVirtualDesktopCollection $CollectionName
$RDCOll | Set-RDVirtualDesktopCollectionConfiguration -ClientDeviceRedirectionOptions Clipboard,Drive,AudioVideoPlayBack -RedirectAllMonitors $false -SaveDelayMinutes 5

Also, here’s the unattend file I’m referencing. Notice that you don’t need to specify domain join details or computername, as these will be dynamically injected into the unattend file as the vms are deployed (mind you, I’m deploying x86-based VMs at the moment, so if you want to use x64-based VMs you need to use the corresponding x64 components in the unattend file).

<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="specialize">
<component name="Microsoft-Windows-International-Core" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="<a href="http://schemas.microsoft.com/WMIConfig/2002/State">http://schemas.microsoft.com/WMIConfig/2002/State</a>" xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001/XMLSchema-instance</a>">
<InputLocale>0414:00000414</InputLocale>
<SystemLocale>nb-NO</SystemLocale>
<UILanguage>nb-NO</UILanguage>
<UserLocale>nb-NO</UserLocale>
</component>
</settings>
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="<a href="http://schemas.microsoft.com/WMIConfig/2002/State">http://schemas.microsoft.com/WMIConfig/2002/State</a>" xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001/XMLSchema-instance</a>">
<OOBE>
<HideEULAPage>true</HideEULAPage>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
<NetworkLocation>Work</NetworkLocation>
<ProtectYourPC>3</ProtectYourPC>
<SkipMachineOOBE>true</SkipMachineOOBE>
<SkipUserOOBE>true</SkipUserOOBE>
</OOBE>
<UserAccounts>
<AdministratorPassword>
<Value>WouldntYouLike2Know</Value>
<PlainText>false</PlainText>
</AdministratorPassword>
</UserAccounts>
<WindowsFeatures>
<ShowMediaCenter>false</ShowMediaCenter>
<ShowWindowsMail>false</ShowWindowsMail>
<ShowWindowsMediaPlayer>false</ShowWindowsMediaPlayer>
</WindowsFeatures>
</component>
<component name="Microsoft-Windows-International-Core" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="<a href="http://schemas.microsoft.com/WMIConfig/2002/State">http://schemas.microsoft.com/WMIConfig/2002/State</a>" xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001/XMLSchema-instance</a>">
<SystemLocale>nb-NO</SystemLocale>
<UILanguage>nb-NO</UILanguage>
<UserLocale>nb-NO</UserLocale>
<InputLocale>0414:00000414</InputLocale>
</component>
</settings>
<cpi:offlineImage cpi:source="catalog://tp-fil01/pc-deployment/operating systems/win7sp1x64no_office2013_patched20130417/win7sp1x64no_office2013_patched20130417_dep07ddrive.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

The PowerShell profile is a script file that gets executed everytime you start the PowerShell shell. It’s where you put your own aliases and special commands and other stuff that make your day just a little bit easier. The location of the Profile script is stored in a variable itself, $Profile. To see if you have one, you can simply type:

test-path $Profile

If you want to create one, it’s easiest done by typing

new-item -itemtype file -path $profile

And you’re off!

Anyways, to the subject. I try and keep a fairly organized folder structure for all my scripts and modules, which now counts upwards of 2000(!) files. In my documents folder, I have a scripts folder, and inside it I have a folder for each language I work with. The two I work with the most are PowerShell and SQL Server scripts.

Inside my PowerShell folder, I have subdivided my scripts into the following:
-3rd-party scripts: Modules and scripts I download from the masters, like the WMI Explorer script which I honestly could not live without.
-Normaldev: scripts I’m working on. Anything from rough outlines and ideas to working scripts
-Moduledev: Scripts I’ve built into PowerShell modules (more mature than the ones in my “normaldev” folder)
-Utilities: Small scripts that are usually referenced by my Profile

This works for me. It gives me a fairly organized way of working with stuff from inception through finishing a module and releasing it onto servers or GitHub if it’s part of a more formal product.

This all means that whenever I fire up PowerShell, chances are good that I want to quickly navigate to that PowerShell scripts folder. Here’s a few lines of code I’ve put in my profile to make that as easy as possible:

function get-SpecialFolder { 
  param([System.Environment+SpecialFolder]$Alias) 
  [Environment]::GetFolderPath([System.Environment+SpecialFolder]$alias) 
}

$DocsFolder  = get-SpecialFolder MyDocuments
$PowerShellScriptsFolder = "$DocsFolder\Scripts\Powershell"

function GoTo-PowershellFolder
	{
		Set-Location "$DocsFolder\Scripts\Powershell"
	}
	
function GoTo-DocsFolder
	{
		Set-Location $docsfolder
	}

New-Alias -Name gtd -Value GoTo-DocsFolder
New-Alias -Name gtp -Value GoTo-PowershellFolder

Since the path to my documents folder varies from computer to computer, I’m using Windows built-in “SpecialFolder” functions go get to my documents path. From there, I can construct variables for my “Documents” path, and thereby my “PowerShell” path (which is in Documents\Scripts\PowerShell).

So, with some easy-to-remember aliases I can fire up PowerShell, and simply write

gtp

and I’m where I need to be.

Happy profiling!

In order to support a more advanced CI process and virtualize the few production systems we have, I invested in a HP DL 380G8 server and new switches all around. We’re now on gigabit links all the way out to each workstation, and floors are connected to each other with a 2Gb link. For switches, I bought 3 Netgear GSM7224V2 switches. For our use, these work wonders at a fraction of the price of Cisco units.

Using Windows Server 2012 on the new HP server, we’re using all 4 NICs on the server in a so-called “converged fabric”.

Anyway, what I was gonna tell you anyway in this post, is that Windows Server NIC teaming in LACP mode works nicely with Netgear LAGs (Link Aggregation Groups). Simply define a LAG on the NetGear switch and add the switchports connected to your converged fabric. On the Windows Server, define a NIC Team using LACP/Address Hash, and witness a nice increase in network speed:

BTW; Read this blog post for more details on nic teaming.

There is a document here outlining how to generate a self-signed certificate, but it doesn not work – the produced certifice will not be accepted by Azure when you try and upload it to the portal. Among other things, the doc states that the certificate expiry date can not be more than 3 years into the future, a fact the how-to does not consider.

Anyway, here’s my “how to create a certificate for Azure Recovery Services Backup”:

1. Download the makecert tool from the Technet gallery, if you don’t already have it installed. If you’re running visual studio 2012, you can find it using the Visual Studio prompt on your start menu, uh screen.

2. Run the following command to generate the cert (all on one line). You MUST run this as admin:

makecert.exe -pe -n “CN=Azure-Recovery” -EKU “1.3.6.1.5.5.7.3.2″ -SR localmachine -SS my -R -len 2048 -m 36 Azure-Recovery.cer

3. Start MMC, add the Certificates snapin and open your computer store (not user or service)

4. Under Certificates–>Personal–>Certificates, find your newly created certificate. The expiration date should be exactly 3 years into the future

5. Right-click the cert, choose “All tasks”–>Export

6. Choose “No, don’t export the private key”

7. Format should be the first in the list, DER encoded binary X.509

8. Export to a file name of your liking

9. The produced certificate is the one you’re gonna upload to Azure Recovery Services. I actually had to try twice to get the certificate accepted.

So, we came up with the idea that we’ll just use PowerShell against the reporting services webservices instead. Much better. One thing to notice: When you upload a report using the webservice, SSRS is not smart enough to link the reports datasets/datasources, even if you already have these published in SSRS. So much of the code in the module is about relinking reports and datasets after they’ve been uploaded.

I’m not getting piping from Get-SSRSItem to Remove-SSRSItem to work, so that’s work in progress. Otherwise everything seems to be working nicely. Also, since our standard reports only have one datasource, I haven’t built functionality for uploading datasources, only reports and datasets.

Some of the code comes from Randy Paulo’s excellent blog, which is well worth adding to your rss reader.

So, consider this work in progress. I hope you’ll find it useful

Downlad link:
http://hindenes.com/powershell/SQLReporting.psm1

#Params to fill in
$VMName = "TimTest208"
$InstanceSize = "Small"
$ImageLabel = "Windows Server 2012 Datacenter, March 2013"
$VMPassword = "pass@word1"
$VMNetName = "TIM-VMNET-NE-01"
$VMSubnetName = "TIM-VMNET-NE01-SN01"

#Begin Script
$StorageAccount = (Get-AzureStorageAccount).Label
Get-AzureSubscription | Set-AzureSubscription -CurrentStorageAccount $StorageAccount
Get-AzureSubscription | Select-AzureSubscription

$AG = (Get-AzureAffinityGroup).Name
New-Azureservice -AffinityGroup $AG -ServiceName "$VMName" #This will be the service Public DNS Name created by azure
#This sometimes takes a few secs, wait-looping
    $FirstLoop = $true
    Do
        {
            if (!$FirstLoop)
                {
                    Start-Sleep -Milliseconds 500
                }
            $Cloudservice = Get-azureService | where {$_.Label -eq $VMName}
        }
    Until ($CLoudService)
$CLoudServiceName = $CLoudService.Label
$ImageName = (Get-AzureVMImage | where {$_.Label -eq $ImageLabel}).ImageName

$VM = New-AzureVMConfig -Name $VMName -InstanceSize $instanceSize -ImageName $ImageName
$VM | Add-AzureProvisioningConfig -Windows -Password $VMPassword
$VM | set-azuresubnet -SubnetNames $VMSubnetName
New-AzureVM -ServiceName "$CLoudServiceName" -VMs $VM -VNetName $vmnetname

#Uncomment the next line if you want to enable RDP on the VM's public IP
$VM | Add-AzureEndpoint -Protocol tcp -LocalPort 3389 -Name "RDP in"
$VM | Start-AzureVM

And no – this isn’t going to be one of those 14-page rewievs of the Lumia 920, there’s already enough of those out there. I simply wanted to touch on the good and the bad when switching from Android to Windows.

So, after living in relative harmony with my Samsung S3 (which I used a lot) and my Android-based ASUS Transformer TF101 tablet (which I didn’t use that much), I’ve switched to a Windows Phone 8-based Nokia Lumia 920, and a Windows RT-powered ASUS Vivotab RT tablet.

Before I’m going any further, it’s worth pointing out that both my Samsuns S3 and my ASUS TF101 were loaded with custom ROMs to get that nice “android” feeling – I can’t believe how much crap the vendors put on top of a very good OS (Android ICS, that is). Kind of reminds me of bying a Toshiba laptop, if you know what I mean…

I chose the Lumia 920 simply because I think it’s a nice-looking phone. The ASUS tablet might be a tougher sell – why not the Surface RT? As it turns out, the ASUS Vivotab is the only Windows RT-powered tablet with a sim card slot for sale in Norway. Also, when trying the Surface RT I didn’t like the way it “felt”, especially in upright mode. My wrists actually got tired from holding the thing when reading a Kindle book. The ASUS unit feels light, has the same guts as the Surface RT and is always connected as long as I’m within 3G coverage. Nuff said.

Switching from Android to Windows Phone 8

I don’t consider myself a heavy mobile phone user. Corporate email, some Facebook and a lot of Google Reader reading when waiting for someone/the bus or just killing time.

Powering up the Lumia 920 I went. “Damn. This is weird. I just have kept my S3″. However, after a few days of use, I really like the flow of the OS. The “people hub” works as prescribed and all in all it’s an effective little thing.

My android phone would constantly skip to the next song or whatever when I was out walking or moving about, because the android (so-called) lock screen is far from a lock screen – you can basically operate the entire phone without unlocking it. Not so with the Lumia 920. When the phone is locked, it’s locked. Basic volume controls and play/pause are all you get. My songs have stopped skipping on me, and I’m thankful for it.

As far as apps go - you know the story. Still some are missing. For the life of me I can’t unerstand why a good podcast manager is so hard to come by, but hopefully that will come with time. The updated twitter client works well, Microsoft’s facebook app is good enough, and all the email/calendar stuff works wonders.

Do not, however, expect to do any reading on the device after bedtime. The device does not have a rotation lock, which must be by far the biggest missing feature in Windows Phone 8. Apps rotate here and there, and sometimes they rotate midway in the app. Try and search up and install an app from the Marketplace and you’ll know what I mean. The fact that such a a beatiful screen is rendered useless after bedtime is simply beyond me.

with the exception of the lacking screen rotate, the Luma 920 is a very nice phone. After 2 days of use, I really fell in love with it. I’m putting my S3 in a drawer as we speek.

The ASUS vivotab RT

I have been using Windows 8 since the betas, but I have to admit: although I love the core OS, I’m not so sold on Microsoft trying to “tabletize” my work laptops. I’ve been running various start-screen replacements such as stardock and pokki to try and get back some of the lost “Windows 7 feel” of the OS. On a tablet device though, the platform just shines. My iPad-using friends are jeleaus of the beuatiful and elegant os and the rich interaction it offers. On the tablet form-factor, I’m all in.

My only gripe was the fact that I couldn’t get gmail setup as an activesync account on my ASUS. Google is killing off their activesync support, but I’ve been under the impression that it would still work until around June 2013 or whatever. Which means that I’ll be switching my domain to outlook.com as soon as the butt-ugly hotmail-style calendar gets a facelift. In the meantime, I can live with IMAP-based gmail.

One thing worth mentioning: Windows RT doesn’t come into its own until you start using Windows 8 on your main computer, and link your local user account to a Microsoft account. The background syncing Windows 8 and RT is doing with skydrive is just terrific. Recently visited websites, saved passwords, WLAN keys - it’s a small thing but it works so effortlessly it almost feels like magic.

IE 10 on the Windows RT is by far the best browser I’ve tried on any tablet. I find it a lot smoother than Google Chrome on Android ICS, but it may not be a fair comparison since my android tablet suffers from a lot slower hardware than the ASUS Vivotab does. The fact that Flash content is only available on “approved sites” is just plain stupid.

I also got the keyboard dock for my ASUS. I love the fact that it’s adjustable. The Surface RT kickstand is nice in theory, but the angle must have been decided by a midget (or by a designer with a weird sense of humor). I could barely see the screen when I put the Surface in kickstand-mode, so the adjustability of the ASUS dock is refreshing.

To be honest, I don’t really need a tablet. I always bring one of my laptops with me when travelling anyway. Its just nice to be able to watch a movie and do some light typing without firing up the big guns. For working while flying economy, the ASUS really shines. I love the OneNote MX app especially, and have also found a Google Reader client to my taste.

Unlike the Windows Phone 8, the Windows RT acually does have a orientation lock. It does not work globally, so excpect a few apps to pop the wrong way while in bed trying to use the tablet in portrait mode. The Kindle app seems to “respect” the orientation lock though, so you’re able to read your Danielle Steel novel.

The ecosystem

I while back, I wrote a blog post on trying to stay in sync on my android devices. I’ve been living in relative peace with all my devices. I chose to use SugarSync for file syncing a long time ago, and I have not looked back. Why Dropbox is more popular than SugarSync baffles me, since I find the latter so much better. Anyhow, Microsoft kind of takes it for granted that SkyDrive is the way to sync files. Although “syncing” is not the right word, “access” would be better. Windows Phone 8 will automatically send your captured photos to SkyDrive, and both Windows Phone 8 and Windows RT has built-in apps for accessing files and photos in Skydrive. There’s nothing wrong with SkyDrive, but it’s still lacking some features I need. SugarSync is working on an app for Windows Phone 8, hopefully that lets me send my photos to my SugarSync folders instead of SkyDrive.

If there’s one thing I miss on these two mobile platforms, it’s not being unable to upload pictures of my dinner to Instagram (Lasagna, by the way). It’s the fact that there is an app missing from both platforms, and that’s a good podcast manager. Preferably one that syncs my subscriptions from one device to the other. I would be willing to pay for that.

Apart from that, I’m extremely happy with both my devices, and very excited about what’s to come. The future is Blue!