Today is the day that I’m joining KPN Consulting as a Technical Consultant focusing on Remote Desktop Services and the Enterprise Mobility + Security Suite. In the past years I’ve done great projects for Inovativ but today I’m really excited about joining KPN Consulting and want to help customers of KPN Consulting with questions/challenges around the ‘Workplace of tomorrow’ of course within my focus area RDS and EM+S.
At KPN Consulting I will continue to share knowledge through my blog and when speaking on events. So stay tuned for more blogposts around Remote Desktop Services and the Enterprise Mobility + Security Suite. One last note which I want to make is the information which you will find on this blog is my personal opinion and not the opinion of my employer.
In this blogpost I want to show you how you can easily create a PowerBI dashboard based on Storage Spaces Direct performance metrics. PowerBI is great in visualizing data and reports are easy to create. Before you can execute the steps in this blogpost you will need to create a PowerBI account on https://www.powerbi.com. I’ve tested the blogpost below with PowerBI Pro account but based on this page it should also work with a PowerBI free account. Looking to Storage Spaces Direct this blogpost is based on Windows Server 2016. I’ve not tested this on earlier versions and I expect that this is only working on 2016 and later. I’ve created this blogpost to monitor my S2D environment hosting the Remote Desktop Service User Profile Disks, so expect that this dashboard is focusing on delivering an overview for that purpose.
On the 1st of January I received an awesome email. Microsoft presented me my second MVP award in the category: Enterprise Mobility. This is really a great start of 2017! I’m really proud and honored that my contributions are rewarded with a MVP Award. I will continue sharing my knowledge by presenting on events and blogging on this blog. The focus will remain the same: Remote Desktop Services and the Microsoft Workplace Solution (Enterprise Mobility + Security Suite and Windows 10).
Thanks again to Microsoft and you as a reader of my blog!
This year started great with receiving my first MVP Award. I really like sharing my knowledge with the community! This year was also the year that Azure RemoteApp were retired by Microsoft, based on that decision the focus has become Remote Desktop Services and the Enterprise Mobility Suite. I want to share some statistics of this year with you. This blogpost will also be the last blogpost of this year!
The last couple of weeks I was thinking about could a RDS environment be used together with Device Based Conditional Access (CA) provided by AzureAD and Microsoft Intune. With AzureAD CA you can configure this based on the user, the device of the user, the application and the risk of the request. This blogpost only covers Device Based Conditional Access. When Conditional Access for Devices is configured the devices either need to be domain joined (AD and AzureAD) or compliant to the configured compliance policies. These policies need to be configured within Microsoft Intune or System Center Configuration Manager. This blogpost will focus specific on the use of RDS 2016 Session Hosts together with Conditional Access.
With Remote Desktop Services 2016 we can use Azure SQL Database for hosting your RD Connection Broker Database (RDCB). Back in the RDS 2012 days we had to either build a SQL Mirroring or SQL Always On solution to provide High Availability to the RD Connection Broker database. Both SQL HA solutions were expensive especially on Azure. As a best-practice SQL needed to have premium storage for hosting the data and log files. Now with RDS 2016 we can use Azure SQL database for the RD Connection Broker database, but how about sizing the Azure SQL database service. In Azure SQL database you cannot simply chose the number of CPU cores and Memory which you want to use. On the Azure SQL database platform the performance is measured by Database Transaction Units (DTU’s). In this blogpost I want to explian how you can collect some performance metrics from your existing SQL Server and size your Azure SQL database.
Last week I finally published my first Azure ARM template for deploying a RDS environment. This template was based on a Azure AD Domain Services environment and depends on the Azure AD Application Proxy for publishing the RD Web and RD Gateway role. The good news for this deployment was that no DMZ was necessary. The bad news was that the UPD channel of the RD gateway cannot be used. Today I will publish a template which is based on a existing Azure Active Directory (not specially Azure AD Domain Services) and on publishing the RD Web and RD Gateway roles in the DMZ for publishing the environment. This template is basically re-using 75% of the template and scripts of the Cloud Only Deployment.
After my visit of MVP Summit and speaking on ExpertsLive I’ve finally some time to produce some blogposts which were staying @ the backlog of my blog. Starting with the last part in the series ‘how to deploy your cloud-only RDS environment’. In part 1 till 4 the environment is described and also the instructions how to create the same environment in your own subscription. In this last blogpost I’m describing how to deploy the RDS environment with a Azure ARM template. In part 3 and 4 I already explained the scripts used by the template to deploy a Storage Spaces Direct cluster and the Remote Desktop Services environment. With a Azure ARM template we can deploy all the needed resources on Azure and also execute the scripts on these servers.
A very short blogpost about an deployment error which I had this week:
This week I had an issue with configuring the User Profile Disk mechanism in a fresh Windows Server 2016 RDS environment. Every time when I try to enable the user profile disk mechanism it came back with the error: Could not create the template VHD. Error Message: -800391163. So the User Profile Disk mechanism was not activated and the template VHD was not created, however the NTFS rights where configured on the share. I tried several things but the solution was pretty easy. In my case this error came through a misconfiguration of the share permissions of the share. So the NTFS permissions were configured as needed but on a share level the RD Broker/Session Hosts didn’t had access. When I granted access to those servers the issue was fixed and I was able to configure the User Profile disk mechanism on the collection.
This week I made some really nice progress in achieving my end goal: ‘an automated Cloud Only Remote Desktop Services deployment’. This series consists of multiple blogposts, each blogpost covers a section which describes in detail how to configure the used technology. In the first blogpost of the series I described that this series is based on a CloudOnly deployment of RDS 2016 with as much PaaS services as possible and using Azure ARM templates for deploying the resources. The good news is that with all the progress made this week I’ve a working deployment which creates all the resources, configures Storage Spaces Direct as high available storage solution and a high available Remote Desktop Services environment.