In a recent update to the iOS Remote Desktop client (8.1.0 and above) you receive the following error when connecting using a Remote Desktop Gateway: Can’t connect to the Remote Desktop Gateway. Contact your network administrator for assistance. (Error code: 0x03000008)
Confirmed on the Remote Desktop Services blog here.
1. Review the TerminalServices-Gateway operational event log on the Remote Desktop Gateway server and look for EventID 301 which states: The user “DOMAIN\user”, on client computer “184.108.40.206”, did not meet resource authorization policy requirements and was therefore not authorized to resource “172.17.50.10”. The following error occurred: “23002”.
The resource IP should be one of your RDS servers, note healthy connections to the Gateway should (typically) specify the FQDN of the RDS server it is trying to connect to: The user “Domain\user”, on client computer “220.127.116.11”, met resource authorization policy requirements and was therefore authorized to connect to resource “RDS-NY-2.domain.co.uk“.
From the SBS 2003 server open a command prompt and run netdom query fsmo – confirm the SBS 2011 server is currently holding the FSMO roles. The procedure below gracefully transfers the FSMO roles back over to the SBS 2003 server.
connect to server SBS2003
Transfer domain naming master
Transfer infrastructure master
Transfer RID master
Transfer schema master
Run netdom query fsmo and confirm that the SBS 2003 server now holds all of the FSMO roles. The time limit has now been extended by 7 days.
After the 28 day period (21 plus the 7 above) – Disable Shutdown
This method will prevent the source SBS 2003 server from shutting down indefinitely. From the SBS 2003 server transfer the FSMO roles back to the SBS 2011 server.
Split-scope is a quick and easy way to provide redundancy and load balancing for DHCP in your network. Server 2008 R2 introduces a handy wizard for creating a split-scope and saves some administrative effort, however it can only be used if both servers are running R2.
Here are two ways in which you can utilize split scope.
Primary / Backup
In this scenario, the 1st DHCP server will dish out all leases and the 2nd DHCP server should only be utilized if the 1st server fails. You can accomplish this with the “Delay in DHCP offer” setting when configuring split-scope (prior to to 2008 R2 you could use the “Conflict detection attempts” for the same effect). DHCP clients accept whichever server responds first to the DHCP DISCOVER packet, so we delay the response from the 2nd server which allows the 1st to respond and therefor serve the client.
Here is the 80/20 rule in action
Now, as you’ve probably guessed the 80/20 is rather arbitrary, and can be shuffled around to suite your network.
For this method you’d leave the “Delay in DHCP offer” equal when configuring split scope, which would give both servers a 50% chance of dishing out leases. You’ll probably want to set the scope to 50/50 and I’d make sure that each 50% could serve the majority if not all of the clients in your network.
Configuring Split Scope
Here we will setup the 80/20 rule. In versions prior to Server 2008 R2, you would have to manually configure the scope on the 2nd server, the wizard included in R2 does this for you.
At this point you should have 2 DHCP servers configured. The 1st server should have a scope with the full range of addresses, and the 2nd server should be scopeless. In this example I’ve configured the scope on AD1 for 10.0.0.100 – 10.0.0.200 and added both DHCP servers to the DHCP MMC console.
Right click the scope, select advanced and then Split-scope
Add the 2nd DHCP server
Adjust the split, here we choose 80/20- note it will show you amount of addresses each server will have and the excluded range
Here is the delay in DHCP offer I mentioned earlier, for 80/20 you’ll probably want to use 1000ms for the 2nd DHCP server. If you wanted to load balance, leave both of these at 0
The scope will now have been added to the 2nd server, to finish the setup, right click the scope and choose activate
In this video I will walk you through configuring the DHCP role and split scope.
We use System Center: Data Protection Manager for backups. On February 1st of 2011, the annual backup of one of my protection groups was running. Since it was scheduled for January 1st, I was a bit confused. I opened a ticket with Microsoft support and thus began a very long adventure into the DPM scheduling agent. The end result is that the issue is a bug triggered by an interaction between DPM and SQL Server that can be triggered under specific conditions that causes the behavior above.
Modify a protection group that has a long term retention schedule that is on anything other than a weekly or monthly basis and NOT adjust the timing of those backups.
The job is recreated in the SQL Server Agent without modifying the Start Date. This will cause it to trigger inappropriately, by running when it shouldn’t as well as failing to run when it should. This is due to the fact that although the start date didn’t change, the last run date is lost. Since the jobs are actually configured to run on X date (or day of the week/month/year) every x period of time instead of exact dates, this means my January 1st run date is configured as run on the 1st of the month every twelve months. Because of this it runs on the 1st of the next month if I trigger this bug.
How can you confirm this issue is going to happen to you? The easiest way is to use a script I was provided by Microsoft Support. A copy of the script is in the zip file available here.
The first time I ran the script I got an error. I re-ran it however, and it executed properly. I was told this is a bug in the script as it is currently defined. The output will look something like this:
Name SQL Agent
Job Definintion ID
Schedule Create date/time
Last run date/time
Next run date/time
This is an example of one of my protection groups. Fields in italics have been altered to anonymize the data. The text in red is the one that is likely to have the issue. Should I modify this protection group at this time without entering the Modify Schedule dialog it WILL end up running a backup on the 1st of the following month since the start date is in the past.
As of now, there is no fix for this behavior. There is, however, a way to work around it. As mentioned in the Trigger section this only happens when you don’t open the modify schedule button. So what happens if you do? The Start Date is reset and the entire schedule will run as planned. When editing a protection group and you get to this screen:
You need to click on the Modify button on the Backup Schedule area so you get this screen:
Click OK on this screen to close it out. As long as do this the Start Date for the backup schedule will be reset so that it is correct. This will avoid triggering the bug and keep your backups on schedule.
At this time Microsoft has indicated that a script to fix this will be given to me in the relatively near future once they have the bugs worked out. Additionally either in DPM 2012 or DPM 2012 SP1 this issue will be resolved so the scheduler no longer causes this issue. At this time, they are unsure if the bugfix will be ported back to DPM 2010.
CTxAdmTools provide a handy tool for removing HP’s Proliant Support pack. I’ve used it on a number of occasions typically when P2V’ing HP servers, and it’s a great time saver. Once the server is virtualized you’ll want to remove the PSP as it may cause issues further down the line and it’s simply software and drivers that you won’t need on the system any more. I’ve seen people recommend removing the PSP prior to the P2V process, but I believe it’s best to keep the source server ‘as is’ if you need to backout of the procedure.
Server 2008 introduced ‘Fine Grained Passwords’ (FGPP), which allows multiple password policies in a single domain. Prior to Server 2008 there was a limitation of one per domain.
To achieve this you will need to create a PSO (password settings object) which applies at the user or security group level. There are 3rd party applications out there to for this, but personally I find using ADSI straight forward enough.
The domain functional level needs to be 2008 or higher.
Let’s get to it!
Administrative Tools – ADSI Edit
Actions -> Connect
CN=Password Settings Container
Right click select new -> object
You’ll be presented with a set of options which are explained below.
Common-Name – Friendly name to identify the policy Password Settings Precedence – Think of metrics, if a user is in two groups the policy with the lower precedence will win Password reversible encryption status – No need for this in our example and generally bad for security true/false Password History Length – How many passwords does a user have to use before being allowed to return to the first Password Complexity Status – Password Complexity true/false Minimum Password Length – Minimum Password Length Minimum Password Age – Minimum time before the password can be changed. This is set in Days:Hours:Minutes:Seconds, so for 1 day you would use 1:00:00:00 Maximum Password Age – Maximum time a password can be used This is set in Days:Hours:Minutes:Seconds, so for 90 days you would use 90:00:00:00 Lockout Threshold – How many times the password can be entered incorrectly before the account is locked out Observation Window – The time in which incorrect passwords are logged, for example if we set 5 above, and 00:00:20:00 for this, if more than 5 incorrect passwords are typed within a 20 minute period the account will get locked out Lockout Duration – If the account is locked out, the duration in which it stays locked out. This is set in Days:Hours:Minutes:Seconds, so for 1 hour you would use 00:01:00:00
Select ‘More Attributes’
Select a property to view and change to ‘PSO Applies to’
Get the DN (distinguished name) from ADUC (active directory users and computers). You will need to select advanced features in the view menu at the top. Double click on the group or user this PSO will apply to, select the attribute editor tab and find the distinguishedName attribute a small distance down. Copy and paste this into the edit attribute box in ADSI edit.
We can test if the policy has been applied by resetting a password for a user in ADUC or by typing dsget user DN -effectivepso , if dsget succeeded is returned without anything else displayed you went wrong somewhere as this means the default domain password policy is still in effect. This is what you want to see:
Today we’ll look at setting up a quick PPTP VPN from Server 2008 R2 with 1 network card.
Server Side (Server 2008 R2)
Head to Server Manager, right click and Add Role
Select Network Policy and Access Services
Select Routing and Remote Access Services, next, next until complete
Expand Roles, right click on routing and remote access and select configure
If you select “Remote Access” give the following error “Less than two network interfaces were detected on this machine. For standard VPN server configuration at least two network interfaces need to be installed
Select Custom Configuration to get around this, then select VPN Access
Right click Routing and remote access and select properties
Browse to the IPv4 tab and assign a static pool of IPs for the remote clients
Now load up ADUC (Active Directory Users and Computers) and double click the user you wish to give access
Select the Dial-in tab and set the Network Access permission to Allow Access
Client Side (Windows 7)
Head to Network and Sharing Center
Select Set up a new connection or network
Select Connect to a workplace
Select User my internet connection (VPN)
Enter the IP/Host of the VPN server you configured earlier, give the connection a friendly names
Enter the username, password and domain
Click Skip before it tries to connect (if this is a remote system it will cut you off, you can get around this by disconnecting the client from the RRAS interface)
Click Change adapter Settings in the main Network and sharing Center
Right click the VPN connection you just created and select properties
Go to Networking, IPv4, Properties, Advanced and unselect Use default gateway on remote computer
You should be ready to connect!
Enable forwarding for TCP Port 1723 (PPTP) to your 2008 R2 Server