Trying to enable EFS on a specific OU, while it’s disable at the top of the structure or domain?
Recovery certificates from two different GPOs mixing up instead of being replaced?

Overall EFS GPOs looking like they aren’t merging properly?

Well, it’s not because EFS GPOs are supposed to behave like black magic. Turns out there’s a bug, Microsoft’s aware of it, but doesn’t think it would be a good idea to FIX IT on Windows XP and 2003.

Thankfully, all it means is you need to edit your GPOs from a Vista, 2008 or Windows 7 machine.

KB : EFS may not be enabled expectedly after you disable a policy and this policy turn off the EFS feature

Opening my EFS GPOs in Windows 7, switching the Allow/Don’t allow and applying the ‘change’ fixed my GPOs. A few minutes later, and stuff was behaving like it should’ve been… Can I have those wasted hours of my life back, Mr. Ballmer?

After looking at the WindowsUpdate.log file, you notice an error, WARNING: WU client failed Searching for update with error 0x8024400e .

You then find info about
1) This error being related to Office 2003 Service Pack 1, and that unapproving it fixes the isse
2) Microsoft having released a patch for this issue that you can install on your servers.

But in reality, the issue might be…
3) You’re retarded, and called a computer group on your test lab .. Group! .. With the ! !

It doesn’t provide great security, and you really should be using full drive encryption anways.

But in case anyone is wondering, for a 1.5gig swap file, this option (ClearPageFileAtShutdown) seems to add about 30 to 40 seconds of time to the shutdown procedure as it overwrites the file with zeroes.

Now turn it back off and install Truecrypt!

Let’s say you have 500 servers. All servers run some agent service that must always be set to automatic, and for which you have customized ACLs. (You grant helpdesk the right to restart the service for example).

Well, this is pretty easy to handle as every service can be handled in different GPOs, so you just create a GPO with your settings, and you link it appropriately.

Now, what if you want to grant the service account that this service uses on every computer the right to “Log On as a Service” ? You could put that in the same GPO, but it would override any other policy that has “Log On as a service” defined and is applied before this one. Wouldn’t it be nice to be able to specify in a GPO that the service account must have “Log on as a service” while keeping the currently specified rights?

When I use Windows virtual machines, sometimes the system beep gets annoying to my neighbors.

When I use Linux virtual machines, it goes through my laptop’s PC Speaker, which makes me have a heart attack, and annoys my neighbor.

Find your Vmware preferences file

Windows: Application Data\VMware\preferences.ini

Linux: ~/vmware/preferences (you could possibly do it in the system wide config as well)

Add this line:

mks.noBeep = TRUE

All beeps should be gone.

Windows itself

If for some reason you use some other Virtualization product that does not allow you to disable beeps, just create a Group Policy on your test domain (you could do it local as well). Configure any non critical service in the GPO to be DISABLED. (I use the print spooler).

Once that is done, browse to the sysvol, find the GPO’s folder, and edit the security policy text file. Replace the name of the service you disabled with “beep”.

The reason we have to do that is because you don’t see the beep service in the list of the GPO editor. But this effectively disables the beep service that Windows uses, well, to beep ! I deploy this on test domains where I “beep” often.

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.

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

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!