One of the new features in System Center Configuration Manager R2 is the ability to create Remote Connection Profiles.
What’s a Remote Connection Profile
The Remote Desktop Profile feature in SCCM2012 R2 enables your users to remotely connect to Company RDP capable devices that are not connected to the domain or using personal devices that can connect over public network.
This feature enables you to deploy Desktop Connection Settings to users in your Configuration Manager hierarchy. Organisations using Windows Intune will have the ability to deploy the remote desktop connection settings to the Windows Intune Company Portal.
extract from Microsoft:
“When you specify remote connection profile settings by using the Configuration Manager console, the settings are stored in the local policy of the client computer. These settings might override Remote Desktop settings configured by another application. Additionally, if you use Windows Group Policy to configure Remote Desktop settings, the settings specified in the Group Policy will override those configured by using Configuration Manager.”
Prerequisites for Remote Connection Profiles in Configuration Manager
- A Remote Desktop Gateway server is required for granting access to users outside of the company domain
- Ensure that the current in place Group Policy’s will not effect the Remote Connection Profiles. Remote Connection Profiles are stored in the Client Computer’s Local Policy. Group Policy may override the policy if policy’s are already in place.
- You will need to create a windows firewall exception for connections on the windows domains and private network settings. Configuration Manager will configure Windows Firewall Automatically when deploying the profile, but for all those using third party client firewalls, you will need to create the exceptions. Also for those using group policy to manage Windows firewall, you will need to manually add the exception in Group Policy.
Configuration Manager requirements:
- End Users will need the Work Computers set as the primary device.
- For Access to Work Computers using Windows Intune, must have a active connection to Windows Intune using the Windows Intune Connector Site System Role.
- Set the required Security Permissions to manage Remote Connection Profiles.
For more information on Remote Connection Profiles in Configuration Manager, Please see the Following article http://technet.microsoft.com/en-us/library/dn261214.aspx
Configuring and Deploying Remote Connection Profiles:
You can find the Remote Connection Profiles under Assets and Compliance > Compliance Settings > Remote Connection Profiles
Right Click on Remote Connection Profiles > Create Remote Connection Profile
Enter a name for the Profile
Set the connection settings
Confirm the configuration
Once the profile is created, you will need to deploy it to a device collection.
Right click on the Profile and select deploy.
Once deployed, the profile will show as deployed.
The use of SQL Server 2012 Availability Groups in conjunction with RDS 2012
I have had a few questions on RDCB HA recently so I have provided some useful information on deployments and best practices when using SQL 2012 AlwaysOn Failover Cluster Instances and AlwaysOn Availability Groups.
The RD Connection Broker role is what controls the RDS Deployment which provides connections and reconnections to active sessions to single or multiple RD Session Host Collections or Virtual Machine Pools and Personal Virtual Machine Pools.
Information about the Active/Active RD Connection broker:
Once RDCB HA is configured, you will see that under the Connection broker Options (tasks) that you can Set the Active RD Connection Broker Server. Both RD Connection Brokers are active, this option is used to change the connection broker that is communicating with the management server (RDMS). What this means is, there can only be one active server managing the management server at one time. To summarise: (active) means Both Connection Brokers are managing the user changes but only one RDCB communicates with the RDMS at one time.
Microsoft supports the following SQL Server 2012 High availability setups in RDS 2012.
- AlwaysOn Failover Cluster Instances
- AlwaysOn Availability Groups
- Database mirroring – future releases of SQL will make this feature deprecated.
I would always recommend using AlwaysOn Availably as there is no requirement for shared storage.
AlwaysOn is supported across subnets, but does require two availability group listeners.
for information on the setup of RDCB HA have a look at the following link: http://wp.me/p2DF8F-mZ
Preparing for SQL Alwayson Availability groups
- The SQL Server native client must be on each RD Connection Broker. (ensure you have the correct version number 11 for SQL12 and 10 for SQL2008)
- Create the DNS Round Robin Records for each RD Connection Broker Server using the RDCB IP address’s. I recommend the use of a third party load Balancer like (KEMP Technologies) as you would have to wait for DNS if a server fails or looses connection. In addition to this, Layer 7 load balancers provide health checking of the load balanced services.
- Create a Folder on both SQL Server’s root drive c:\rdcb\ (this is where the RDCB database is going to held)
- If you are using RD Gateway, you will need to add the DNS RR to the RD RAP Policy.
- Configure the Firewall on both Servers to allow access to SQL
- Create a SQL Service account for use when installing SQL
- SQL Availability Groups require the SQL 2012 Enterprise edition.
Before installing SQL:
Ensure you have the following installed:-
- .Net Framework 3.5.1
- Windows Server Failover Clustering (WSFC)
- Select “New Standalone Installation”
- Ensure that you configure the SQL Services with the designated service accounts
- If you decide to use named SQL instances ensure that you remove all dynamic ports from the configuration manager.
- You will need to assign the first RD Connection broker with the dbcreate permission
- Add the ”NT AUTHORITY\NETWORK SERVICE” account to both RD Connection broker ”RDS Management Servers Local Group”
- Add both Connection Broker Computer Accounts to “RDS Management Servers Local Group” on both servers
- Add the “BUILTIN\RDS Management Servers” group to both SQL Servers and give the group (dbcreator and public roles)
- You will not be able to add the DB Owner permission at this point as we haven’t created the Database as of yet.
RD Connection Broker HA Configuration:
When you change the connection broker to HA, you are telling the first connection broker to create a new database on SQL, and then move all the data from the windows internal database to the newly created SQL Server.
As per my Previous Guide on RDCB High availability (http://wp.me/p2DF8F-mZ) Open up RDMS and navigate to > Server Manager > Remote Desktop Services > Overview.
Then right click on the RD Connection Broker for the High Availability Wizard.
Configure High Availability:
- Before going forward, ensure the native client has been configured on the connection brokers to access the first SQL server.
- Enter the Database Connection string as per my previous post
- Enter the location of the SQL Database (c:\RDCB\)
- Enter the DNS Round robin FQDN \ third party Load balancing Virtual Service
The database will now have been created if the HA configuration was successful, you will now need to give both Connection brokers DB_owner permissions on the database so they can write data to it.
- Open SQL Server Management Studio on the server which has had the database created.
- Expand the “database” > Security > Users > BUILTIN\RDS Management Servers and choose properties.
- Under Membership, ensure that “db_owner” is selected.
Adding the second RD Connection Broker
Open up RDMS and navigate to > Server Manager > Remote Desktop Services > Overview, Then right click on the RD Connection Broker and select add RD Connection Broker
before doing this ensure that you have the second RD Connection Broker in the server pool.
Once you have added the second RDCB server, ensure you install the required SQL Certificate. You will need to use the RDCB HA FQDN
Updating the RD Connection Broker Availability DNS Round Robin name after configuration:
Set-RDClientAccessName [[-ConnectionBroker] <String>] [-ClientAccessName] <String> [<CommonParameters>]
Set-RDClientAccessName -ConnectionBroker "RDCB1.company.local" -ClientAccessName " RDHA.Company.com"
Create a Failover Cluster:
- Ensure that you have the Failover cluster feature installed on both SQL Servers
- Open up WSFC Fail over Cluster and run the “Validate a Configuration”
- Once the validation finishes go through the report and fix any errors
- Once your happy click “Create Cluster now…”
- The cluster will require a IP address and a AD Name.
- If the cluster creation fails, you will need to setup delegate the “Create computer accounts” in Active directory.
Pre requisites for the Availability Groups:
- Ensure that TCP/IP is enabled under SQL Network Configuration in the SQL Server Configuration Manager.
- You will need to enable alwaysOn Availability Groups, this can be done in the SQL Server Configuration Manager > under the SQL Server service > right click and Properties
- Restart the SQL Services
- Create a SQL Service account
- Create a folder on a shared network for the initial backup and sync, the SQL Servers will need full control share permissions.
- Take a full backup of the RDCB database ***Important****
Creating a Availability Group:
- On the Connection broker that holds the RDCB database, navigate to the section (AlwaysOn High Availability)
- Right click on Availably Groups and click on “New Availability Group Wizard…”
- Skip the Introduction and specify a Name for the availability group
- Check the RDCB Database and click next
- Add the replica server and click connect.
- Set the Availability group as Automatic Failover and Synchronous Commit.
- Create the Availability group listener (DNS Name, Port and IP address)
- Ensure that the Create Computer Objects permission is set on the RDS Server OU, otherwise the listener will fail.
Configuring RDS to use the created Availability Group:
You now need to change the SQL Native client Server names to the Availability group listener.
You will then need to change Database connection string, This can be done using Powershell:
Set-RDDatabaseConnectionString -ConnectionBroker <active RD Connection Broker> -DatabaseConnectionString "DRIVER=SQL Server Native Client 11.0;SERVER=<Availability Group Listener Name>;Trusted_Connection=YES;APP=Remote Desktop Services Connection Broker;DATABASE=<RD Connection Broker database Name>"
Once you have run the command shown above, check the Deployment properties under High Availability Settings for the availability group Listener Name.
Testing the solution:
Testing can be achieved by disconnecting the Network interface on the primary connection broker or shutting down one of the servers. Look at the WSFC and you should see that a cluster event states “Cluster Node “***” was removed from the active cluster failover cluster membership.
For all those who have a clunky web client, why not increase the Flash Player cache.
This link takes you to a page which allows you to configure your flash player setting:
Set the flash player to 10 MB cache.
Server 2012 R2 Remote Desktop Services brings a new feature called shadowing, which allows administrators to view sessions.
This can be done through the GUI or through the use of Command Line.
As you can see from the MSTSC Connection Usage help Window, there are three new commands that we can use for connecting to end user sessions. There are two types of Shadowing ( view & control) and the option to select “No Consent” which means you don’t need the end user’s approval/permission before connecting to their session.
Here is the command line for Shadowing:
Mstsc.exe [/shadow:sessionID [/v:Servername] [/u:[Username]] [/control] [/noConsentPrompt]]
/shadow:ID Starts shadow with the specified sessionID.
/v:servername If not specified, will use the current server as the default.
/u:username If not specified, the currently logged on user is used.
/control If not specified, will only view the session.
/noConsentPrompt Attempts to shadow without prompting the shadowee to grant permission.
RDS GUI Shadowing:
As you can see from the screenshot provided above, there are three users showing in the connections task pane. By right clicking on the user, you will be presented with the following options:
Select Shadow and you will be presented with a Shadowing options box.
As mentioned earlier, you have the option of viewing , controlling and prompting for user consent. For this example we are going view and request the users permission to shadow their screen.
Once the request has been sent, you will see the Remote Desktop Connection loading box.
The requester will see this box until the end user actions the request.
If the end user refuses the connection, you will see the above error.
When the user selects yes, you will then be able to view their screen.
As you can see from the screenshot, we are now viewing the user’s screen.
If we try and access the User’s session with out their permission, we are presented with the following error message.
This is an out of the box feature and to disable it, you will need to apply a Group policy.
The Group Policy that needs to be changed is located under Administrative Templates>Windows components>Remote Desktop Services>Remote Session Host>Connections. “Set rules for remote control of Remote Desktop Services user sessions”
This can be applied as a user or computer policy.
PowerShell RDS Shadowing:
To shadow User sessions using PowerShell, we first need to Find the session ID’s of our users.
For this I will use the following:
Get-RDUserSession | ft Username, UnifiedSessionId, SessionState, HostServer, ApplicationType -GroupBy Sessionstate -Wrap
The following Cmd organises User Active and Disconnected RDS sessions. This is also useful for reporting.
Once you have obtained the Session ID’s , you can then connect to that session.
mstsc /shadow:<ID> /Control
If you don’t want to request the user’s permission add the /noconsentprompt
For more information on shadowing please see the articles from TechNet and Freek Berson RDS MVP:
I suppose i should start by stating that this post’s main focus is around VMware’s CPU Schedular.
The Difference Between CPU usage In A Physical And Virtual World
Physical servers typically have a single or multiple CPU’s (multiple cores). A hypervisor provides an additional layer between the OS and the physical CPU allowing the use of Virtual Machines (sharing the physical hardware). The Virtual Machine OS talks to the Virtual CPU’s, and requests made from the Virtual Machine are scheduled by the hypervisor (VMware’s CPU Scheduler), across physical CPU cores.
CPU Scheduling enables greater utilisation and sharing of physical CPU resources. This makes virtualisation the favoured choice in modern data centers, as it provided reduced costs, consolidation and greater felxability.
The Performance Impacts Of CPU Processing Using One Or More Virtual CPU’s
A typical physical server has multiple CPU’s available for the hosted primary application. If the server’s primary application is not multi-threaded, you would essentially be wasting the available resources. This is one benefit of using Virtual Machines (maximise resource utilisation).
The first thing to understand when allocating CPU’s to a Virtual Machine, is how CPU scheduling works. CPU scheduling is the process used to allocate physical CPU time slots to vCPU’s in Virtual Machines.
How VMware CPU Scheduling Works:
You have one Physical Hypervisor (ESXI) with one physical CPU, 12 cores and 16 virtual machines. You can have upto 12 virtual machines using CPU resources at one time. The remaining 4 will have to wait. The longer the virtual machines have to wait, the slower they will run.
In addition to this Please see the extract from the vSphere Resource Management Guide
“Single-threaded applications can take advantage only of a single CPU. Deploying such applications in dual- processor virtual machines does not speed up the application. Instead, it causes the second virtual CPU to use physical resources that other virtual machines could otherwise use.”
Some Key Points To Note When Deploying Virtual Machines:
Only allocate the required resources, start off with the minimum and add additional when required.
- 1 vCPU – requests are processed quickly
- Multiple vCPU’s – The hypervisor CPU schedular must wait for physical CPU’s to become available
- Over allocation (commitment) could result in poor performance.
The rule of thumb when allocating CPU’s to a Virtual Machine (Best Practise) is to allocate 1 vCPU and then test the CPU utilisation. When adding Multiple CPU’s you will need to plan your resources better. VMware’s Operations Manager can provide utilisation stats showing possible performance issues.
Key MS products that should be considered for multiple vCPU’s:
- MS Exchange 2010/2013
- MS Sharepoint 2010/2013
- MS Lync 2010/2013
- MS RDS 2012 infrastructure.
For more information on VMware’s CPU scheduler, have a look at the whitepaper
Also have a look at the following article with regards to None Uniform Access Memory (NUMA).
I keep coming across the following error when deploying Server 2012 failover clusters.
“A weak event was created and it lives on the wrong object, there is a very high chance this will fail, please review and make changes on your code to prevent this issue”
Microsoft have released a Knowledge base article to resolve this issue.
I have recently come across an issue where users cannot connect to a Session Host due to a licensing issue.
The following screenshot is presented when users try to connect to the session host.
First things first …. I checked the RD Licencing Diagnoser and no errors showed up (everything green), the session host was configured to point to the licence server, and the licence type was set to User Cal’s.
The root cause of the issue was that the grace period key had not removed on installation of the RD Licencing role.
When I tried to delete the key it returned a permission denied error message. To remove this, I had to go into permissions take ownership of the GracePeriod regkey and then delete it.
(As all ways create a backup of the key first).
Please see the path to the GracePeriod path:
This post will show you how to publish a 2008 R2 Remote Desktop Session in Remote Desktop Services 2012 (R2).
For information on Deploying a RDSH 2008R2 Server in a Server 2012 environment (Click Here)
Publishing a Remote Desktop Session 2008R2
To enable the Desktop Session, you will need to change the RDP Settings located under Remote App Manager.
Navigate to the RD Session Host Server Tab and select the “Show a remote desktop connection to this RD Session Host server in RD Web Access.
As you can see from the screenshot, a new Remote Desktop Connection Icon appears.
There you have it, RDS 2008 Session Desktop Sessions on RDS 2012.