For all those wanting to access the local host of ESXI with Domain credentials rather than root account, have a look at this script.
I have written a script that creates a domain group on the root of ESXI 5.1 so that admins can access ESXI hosts locally with domain credentials. For this to work, the ESXI host will need to be domain joined before running the script.
# VMware ESXI Script to create Domain group on Root of ESXI Host
# Created by Ryan Mangan on the 16/04/2014
[Parameter(Mandatory=$TRUE, HelpMessage="Enter the name of the ESXI Host FQDN")]
[Parameter(Mandatory=$TRUE, HelpMessage="Host Root Password Dual control")]
$DomainAdmin = “Domain Account”
$DomainPW = “Password”
$ADGroup = “Domain\group”
$Domain = “Domain FQDN”
Connect-VIServer SVMHost -User root -Password $HostPW
Get-VMHostAuthentication -VMHost $VMHost | Set-VMHostAuthentication -Domain $Domain -Username $DomainAdmin -Password $DomainPW -JoinDomain -Confirm:$false
Get-VMHost $VMHost | New-VIPermission -Principal $ADGroup -Role “Admin”
Disconnect-VIServer $VMHost -Confirm:$false
This post will show you how to configure the load balancing of RDS 2012 Connection brokers. For the configuration of RD Connection broker high Availability please see the following article (here)
Before we get started with the configuration of the KEMP LoadMaster, I have included some information on other load balancing solutions and why its important to use a Hardware/Software load balancers.
Why you should not use DNS Round Robin
Round Robin DNS (RRDNS) distributes workload among multiple servers but does not provide a mechanism for server availability. If a server within the host fails, RRDNS, unlike Hardware Load Balancing, will continue to send traffic until a network administrator detects the failure and removes the server from the DNS address list. This results in service disruption for clients.
Why you should not use Network Load Balancing (NLB)
- Windows Network Load Balancing is limited to a maximum number of 32 possible hosts in any one cluster
- Load calculations are only based on the network load and Server response time
- All hosts must be in the same subnet
- Each Server Shares the same IP address
- offers basic layer 4 load balancing functionality
Configuring Remote Desktop Connection broker High Availability with KEMP
If you Haven’t already implemented RDCB HA, I would suggest that you configure the KEMP Loadmaster first.
If you are migrating from DNS Round Robin over to KEMP, I would recommend that you add an additional DNS record for the KEMP Loadmaster (run parallel) and once configured remove the old records.
The Connection broker communicates with other connection brokers using the service port 3389.
Create the virtual Service and Set the port to 3389.
Enter in the Service Name, select the service type “Remote Terminal”
Under standard options, you will need to ensure that transparency is turned off and that persistence settings are set to “Session Broker” and a time out of “6 minutes”.
Set the Scheduling Method to “Least Connection” and the Idle connection timeout to “91″ seconds
Set the Real Server check parameters to “Remote Terminal Protocol” Checked Port “3389″
“Ensure that you have added the KEMP Virtual Service A Record to DNS and if using DNSRR, ensure you have removed the old records”
There you have it ! RDS Connection Broker High Availability Load Balanced with a KEMP Loadmaster.
When i logged on to twitter this morning, I found a very nice surprise. VMware announced the awarded VMware vExpert’s (2014). VMware had published the initial list in a blog post here.
I can’t be thankful enough to VMware for selecting me and all my readers out there.
I also want to congratulate the rest of my fellow vExperts for the award, it is a real honor to be on the same list. Please continue with your hard and inspirational work.
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: