The Sysadmins

Tips and tricks from the Sysadmins

Category: Windows Server (page 1 of 2)

Remote Desktop iOS 8.1.0 – Error 0x03000008

Issue

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)

iPhone iPad Error 0x03000008

Confirmed on the Remote Desktop Services blog here.

Fix

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 “1.2.3.4”, did not meet resource authorization policy requirements and was therefore not authorized to resource “172.17.50.10”. The following error occurred: “23002”.

RDS-IP-5

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 “1.2.3.4”, met resource authorization policy requirements and was therefore authorized to connect to resource “RDS-NY-2.domain.co.uk“.

Continue reading

SBS 2003 to SBS 2011 Migration – Extend 21 day limit

You may find yourself in a position where 21 days isn’t enough to finish the migration, if you find yourself in this situation there are two methods for extending this limit.

The methods below should only be used as a short term solution as they technically violate the EULA, but needs must.

How to determine how many days you have left: http://blogs.technet.com/b/sbs/archive/2011/04/14/how-to-determine-the-number-of-days-left-for-sbs-2011-migration.aspx

Extend for another 7 days

This is as simple as moving the FSMO roles back over to the SBS 2003 server (http://support.microsoft.com/kb/255504)

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.

  • ntdsutil
  • roles
  • connections
  • connect to server SBS2003
  • quit
  • Transfer domain naming master
  • Transfer infrastructure master
  • Transfer PDC
  • 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.

From the SBS 2003 server, download and run Process explorer: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Find and right click sbscrexe.exe and choose suspend.

Open regedit and browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SBCore.

Right click on SBCore and select permission, add the administrator account and give full control to this key and subkeys, click yes if warned.

In the right hand pane, change the “start” DWORD to 4 (from 2 default).

Now browse to C:\Windows\System32 and locate sbscrexe.exe. Right click, properties, security -> Add everyone and select deny for all.

Go back to Process explorer and select kill process, open task manager and confirm sbscrexe.exe doesn’t restart.

Configuring DHCP Split-scope in Server 2008 R2

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.

DHCP6

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

DHCP 80_20

Now, as you’ve probably guessed the 80/20 is rather arbitrary, and can be shuffled around to suite your network.

Load balanced

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

DHCP1

Add the 2nd DHCP server

DHCP2

Adjust the split, here we choose 80/20- note it will show you amount of addresses each server will have and the excluded range

DHCP3

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

DHCP4

The scope will now have been added to the 2nd server, to finish the setup, right click the scope and choose activate

DHCP5

Video

In this video I will walk you through configuring the DHCP role and split scope.

Data Protection Manager 2010 – Long Term Backups Not Following Schedule for the Protection Group

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.

Trigger

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.

Effect

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.

Confirmation

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 Protection Group Start Date Schedule Create date/time Last run date/time Next run date/time Tape_Label Time Zone
GUID GUID PGName 06-30-2011 2011-06-30 09:09:37.130 01-21-2012 23:00:00 01-28-2012 23:00:00 Weekly Ignore
GUID GUID PGName 07-01-2011 2011-06-30 09:09:36.173 01-01-2012 23:00:00 02-01-2012 23:00:00 Monthly Ignore
GUID GUID PGName 01-01-2012 2011-06-30 09:09:35.133 01-01-2012 23:00:00 01-01-2013 23:00:00 Yearly Ignore

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.

Workaround

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:

DPM-1

You need to click on the Modify button on the Backup Schedule area so you get this screen:

DPM-2

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.

Fix

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.

P2V – HP Proliant Support Pack Cleaner

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.

You can download the tool here: HP PSP Cleaner

HP PSP Cleaner 15A

Active Directory Fine Grained Passwords with ADSI Edit

Updated post for Server 2012 FGPP

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
  • DC=domain,DC=com
  • CN=System
  • CN=Password Settings Container
  • Right click select new -> object

adsieditpso
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:

DSGET PSO

Server 2008 R2 PPTP VPN With 1 Nic

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!

Networking

  • Enable forwarding for TCP Port 1723 (PPTP) to your 2008 R2 Server
  • The firewall must support GRE

New!

Server 2012 PPTP with 1 NIC guide now up.

 

Older posts