binaryfactory.ca

I wrote this a while ago for my wiki. I don’t use the wiki anymore as I don’t have nearly enough info and time to post good in depth technical articles. I find that the blog is a good place for shorter “tips” like this. Note that this was written before Group Policy Preference Extensions were distributed by MS, and that until everyone uses Preference extensions, this is still useful!

Force regional settings and keyboard language

From BinaryFactory

Contents

• 1 Purpose of this article
• 2 Why do this?
• 3 Solution
• 4 How to do it
  • 4.1 What is setlocale
  • 4.2 Extract setlocale.exe
    • 4.2.1 Make a script
    • 4.2.2 Apply the script

Purpose of this article

Centrally manage the keyboard language settings and/or the regional settings of your client computers or terminal servers/Citrix servers.

Why do this?

It seems Microsoft does not think that forcing a default Regional Setting or keyboard language policy is useful. However, many applications rely on the local date or number format, and using different settings on different client computers can cause a lot of problems. For Keyboard settings, it might be very useful to force a default for a group of users who have a locked down access to terminal server. You would think there is a way to do with with Group Policies, but as of Windows 2003 R2, there isn’t.

Solution

Use setlocale

How to do it

First, download this: setlocale

What is setlocale

Setlocale is a great command line application that does exactly what we need. I have uploaded it to this web site. However, I don’t know the license terms for it. The zip file I found contains a readme with no information about the author or the license. If you are the original author and want me to take it offline or link to your web site, please let me know. I tried to find the original author with no luck, but whoever you are: Thanks a lot.

Extract setlocale.exe

Extract setlocale.exe to a share that is readable by everyone. The location of your login scripts is usually a good spot.

Make a script

In the share where you usually put your login scripts, create a new one. Or if you already have a script applied to the users concerned by this, edit it. \\path\to\setlocale.exe 12345678 12345678

The first number represents the regional language you want to use, and the second one, the keyboard. For a complete list, refer to the readme in the zip file of setlocale.

Apply the script

Apply the script to the concerned users, group or O.U. Assigning login scripts is beyond the scope of this article.

A limitation of Active Directory that I have always found to be extremely aggravating is the Password and Account lockout policy.

You could only set one for the domain..any other policy defined at the OU level would be applied to local accounts only.

How many times did I wish I could set a different password policy for service accounts ! I had to decide between relying on people to use good service account passwords or forcing end-users to use insane passwords. So we had to trust the people creating the service accounts..

Different departments requiring different policies for auditing purposes were also a reason to setup a separate domain. That means at least two new servers, more management time..ew!

In 2008, if you are running AD in Windows 2008 Native mode, you can now create PSOs (Password Settings Objects)  and therefore apply different password policies to different security groups!

This is absolutely awesome and is a very good argument to migrate to 2008.

See this Technet article about Password Settings Objects/Fine-grained password policies , and use this great tool (PSOMgr from Joeware) to play with the settings, instead of using Adsiedit.

I wonder when Microsoft will have a nice interface to create these..

Oh yeah, and my other favorite reason is Read-Only DCs..let’s say they both rank as #1 reasons

Here is a small test I did on DFS Performance.

Setup:

1 Virtual machine running 2003 sp1 as a DC+File server

1 Virtual Machine running 2003 sp1 as a member server

1 Other Windows 2003 sp1 machine that will act as a second DFS host later on 

DFS Root and target folder located on the DC. It shares a folder that contains about 5600 sub folders, but no files for our test.

Locally on the DC/DFS box:

Removing an ACE from the ACL at the top takes about 3seconds. Forcing it to re-apply on all subfolders took about 30seconds.

From the member server, using the non-DFS path (The path is the link target of the DFS)

Adding an ACE and saving the ACL took approximately  210 seconds.

Removing the same ACE and saving took exact 202 seconds (I had the patience to really watch it until it was done this time!)

From the member server, using the DFS path

Adding an ACE and saving the ACL took approximately 225 seconds.

Removing the same ACE and saving took 208 seconds

From the member server, using the DFS path, after we add a second DFS server to host the content with FRS enabled (making sure my Active link is the same box as earlier)

Adding an ACE and saving the ACL took exactly 498 seconds!

Removing the same ACE and saving took 492 seconds !

From the member server, using a totally separate share on the server, which is not part of DFS at all

Adding an ACE and saving the ACL took approximately 119 seconds

Removing the same ACE and saving took approximately 90 seconds

Table of Results

Conclusion

Obviously, setting ACLs locally on the file server is about 67 times faster in my case. Not really a surprise.

On a brand new, best-of-worlds system, setting ACLs through a DFS path is not much longer than with the direct SMB Path of the target. The differences in my test are too small to say there is even a difference, as this is not a 100% controlled environment.

However, setting the same ACLs on a share that is not part of DFS is close to twice as fast.

Notes

If you’re using Windows 2003 with no SP or Windows XP sp1, download this .

My test was done on 2003 sp1 servers, since this is what I had installed right now for compatibility with a client’s system. However, DFS was much improved in 2003 R2, especially regarding DFS replication VS FRS. I would expect performance to be better on an R2 system, and I will run the test when I get the chance to ! Maybe the difference will  be smaller..who knows!