applying Group policy Preferences "Regional Settings" In Vista can have unforeseen results

I am working on a Windows Vista migration project, where i am responsible for designing group policies for Windows Vista. After applying regional settings through Group Policy Preferences, the testmachines started showing strange behavior. These issue's started showing up after the first reboot, since the policy was applied.
These are the symptomes where noted:

1. Client where unable to get an IP address (no ip address could been leased/renewed), although the required services where running. The client did recieve an IP during PXE boot proces (comes from the same DHCP server).
2. The eventviewer was unavailable, allthough the services where running.
3. Unable to release/renew the IP address (RPC service unavailable). Remote Procedure Call service was running fine.
4. Somethimes the test users where unable to log on to the computer.

These isue's where not related to the user, because even after loging on with the local administrative account the same isue's occured. I reinstalled the NIC's on the client, removed all applied policies from the registry. Rebooted the system but still could not get an IP. Troubleshooting also showed that the client couldn't communicate with AD during the Windows Boot Proces, also only cashed domain credentials could log on.

At first i thought there was a problem with the image used for the deployement of the machines. But after redeploying the system I saw there was no issue as long no policies where applied. This pointed me towards the applied policies. The policies where devided in several smaller policies:

1. A general Computer policy (Common Computer policies Desktop Laptop).
2. Desktop Policy (Specific Desktop Policies)
3. A general User Policy (General user policies)
4. An Internet Explorer Policy (General Internet Explorer Policies)
5. An Office 2007 policy (General office Policies)

Started applying the GPO's one by one, which showed that the havoc started after applying the general user policy. This made the GPP's my number one suspect. Braking down and applying the policies over and over again proved my point. After applying the GPP's regional settings the isue starts to occur. Even when only applying the GPP's (no other policy applied) the isue's start to appear.

Compared two registry exports (one before and one after), in the hope to find what was causing the issue, but failed to find the registry entries which where causing these issue's. My troubleshooting did however show that the problem does occur after applying the GPP regional settings.

I did the same testing on Windows Seven RC1, and saw that these issue's are NOT occuring on Windows Seven.

Snapshotting destroys replication.

If you know how Active Directory Replication works, you would be reluctant to use any kind of imaging technology on your domain Controllers. The Active Directory Team wrote a nice artikle explaining why you should or shouldn't use any imaging technology on your DC's.
http://blogs.technet.com/askds/archive/2009/06/05/dc-s-and-vm-s-avoiding-the-do-over.aspx

Unforeseen Outcome

Enforcing the Windows Explorer Classic shell disables tabbed browsing in Internet Explorer.

Enabling the policy User Configuration/Administrative Templates/Windows Components/Windows Explorer/Turn On Classic Shell disables tabbed browsing in Internet Explorer.

Inter-Forest migration. Trust requirements

This small article discribes the trust prerequisites do allow Sid-filtering, which will in return allow migrated users from accessing their resources in the source domain.

Create a forest trust between the two domains.
Enable SID History
[Code]
NETDOM TRUST /Domain: /EnableSIDHistory:Yes /UserO: /PasswordO:
[/Code]
Verified the setting by running the same account, without any value on the /EnableSIDHistory switch.
[Code]
NETDOM TRUST /Domain: /EnableSIDHistory:Yes /UserO: /PasswordO:
Which returned
SID History is enabled on this Trust
[/Code]
When a security principal is copied from one to the other forest it will get a new SID from the Target domain. When SID History is enabled the old SID are added to the SID History of the pricipal. This SID History is added to the session key which it will present while trying to access a share, and thus validating the user in the source forest.

Only enabling SID History is not enough. Windows Server 2003 forest have SID Filtering enabled by default. Security principals in Active Directory have an attribute, called SID history, to which domain administrators can add users’ old security identifiers (SIDs). This is useful during Active Directory migrations because administrators do not need to modify access control lists (ACLs) on large numbers of resources and users can use their old SIDs to access resources. However, under some circumstances it is possible for attackers or rogue administrators that have compromised a domain controller in a trusted domain to use the SID history attribute (sIDHistory) to associate SIDs with new user accounts, granting themselves unauthorized rights. To help prevent this type of attack, Windows Server 2003 automatically enables SID filter quarantining on all external trusts that are created by a Windows Server 2003 domain controller. External trusts that are created using domain controllers running Windows 2000 Server with Service Pack 3 (SP3) or earlier must be manually configured to enable SID filter quarantining. This is also the case when creating a forest trust between two forests. So in order to let the SID History to be passed beyond the trust we need to disabled Sid Filtering on that trust. SID Filtering can be disabled by using following command:
[Code]
NETDOM TRUST /Domain: /Quarantine:No /UserO: /PasswordO:
[/Code]
Again you can verify the status by runnung the same command without specifying a value for the /Quarantine command:
[Code]
NETDOM TRUST /Domain: /Quarantine /UserO: /PasswordO:
[/Code]

Note: Disabling SID Filtering and enabling SIDHistory creates a large security risks and a opens a big attack surgace appon both forests. Therefore it is advicable to speed up the migration. It is understandable that you leave the old environment running for a longer time ones the migration has completed. But be sure to enable the filtering again ones all resource have been moved to the target Forets.

Disabling SIDHistory:
[Code]
NETDOM TRUST /Domain: /EnableSIDHistory:No /UserO: /PasswordO:
[/Code]
Enabling SID Filtering
[Code]
NETDOM TRUST /Domain: /Quarantine:Yes /UserO: /PasswordO:
[/Code]

Copy a Complete OU infrastructure

Somethimes you need to copy a complete OU Structure within a single domain. This can be done by following command:

"FOR /F "Tokens=1 Delims=," %* IN ('DSQUERY OU "OU=%Name OU%,DC=%Domain%,DC=%Prefix%"') DO DSADD OU %*,OU=%Parent OU%,DC=%Domain%,DC=%Prefix%"

Change the %Name OU%, %Parent OU%, %Domain% and %Prefix% with your own parameters.

Example:
"FOR /F "Tokens=1 Delims=," %* IN ('DSQUERY OU "OU=Sales,DC=Contoso,DC=Com"') DO DSADD OU %*,OU=Offshore,DC=Contoso,DC=Com"

Interesting Facts

• Maximum number of objects in Active Directory: A little less than 2.15 billion
• Maximum number of SIDs in in a domain: About 1 billion
• Maximum number of group memberships for Security Principals: 1015*This is for Security groups. Each Security group you're a member of results in its SID being added to your access token at logon.

Note: For Windows 2000 Active Directory environments, the recommended maximum number of members in a group is 5,000. This recommendation is based on the number of concurrent atomic changes that can be committed in a single database transaction.

http://technet.microsoft.com/en-us/library/cc756101.aspx

GPO: Disabling the Windows Firewall in Vista

Microsoft Best practiches advice to keep the Windows Firewall enabled at all times, yet a lot of companies prefer to diable the firewall inside there corporate networks. I know disabling might be the easy way out, as a proper configured firewall can surely be an added value towards corporate security.

Well if you do decide to take the easy way out, following information can be quit handy.

If you would ask me how to disable the Windows Firewall in Microsoft Vista through policy, i've would have answered:
"Enable the policy 'Do not allow the Windows Firewall to be run on your DNS domain'."



Recently I discovered that that polciy has no affect on Windows Vista. If you want to disable the Windows Firewall in Windows Vista you need to disable the policy "Windows Firewall: Protect all network connections".






You will find this setting on two different locations inside Computer Configuration\Administrative templates\Network\Network Connections\Windows Firewall\:

1. Domain Profile
2. Standard Profile

Now what is the difference between these two profiles?

The domain profile applies to when users where able to authenticate to a domain controller (not logged on by cached credentials). When user are connected to the LAN and able to communicate with a domain controller.

The standard profile on the other hand apply when users are unable to authenticate to the domain controller, and by that where logged on by way of cached credentials. Usually when users are not connected to the LAN, and thus unable to communicate (authenticate) with a domain controller (outside the office, hotelroom, etc).

As corporate LAN's are usually protected by enterprise firewalls, it might be acceptable to disable the Windows firewall inside the corporate network (Domain profile). But outside the corporate network it is surely not advisable. So inside the standard profile i would not disable the Windows firewall.

Policy preferences in Vista

Since Windows server 2008, Microsoft introduced policy preferences. A technology they acquired by the acquisition of DesktopStandard. After installing RSAT (Remote Server Administration Tool) on a Vista machine, you will see the preferences appear when opening the Group Policy Editor (GPEDIT.MSC). In order to make use of these policy preferences, your Vista machines need to have the KB943729 (Windows Vista Link/Windows XP link) installed. A windows Server 2008 domain Controller is not required. You can still use Windows Server 2003, as it is the client which needs to have the proper CSE (Client Side Extensions) to process the policies.

System RequirementsSupported Operating Systems: Windows Vista; Windows Vista Service Pack 1

System RequirementsSupported Operating Systems: Windows XP Service Pack 2; Windows XP Service Pack 3

Seizing the Schema master using NTDSUTIL

I have some computers who form an test environment. Now one of these computers showed errors on the system drive, and i knew this disk was about to fail. As this a test environment, the computers used are just simple desktops. So basicly all the machines have a single IDE disk as there system drive. The computer who had the failing disk was the first computer installed for the test environment. And was made Domain controller. As you know, the first domain controller in a new forest/domain, holds all FMSO roles. This was not altered as this DC was ment to be the only DC available (remember test environment).

I wanted to keep the environment running, so i created a second DC (this time virtualized) and transferred all roles accept the Schema Master role. Than due to all sorts off reasons i didnt get arround to move the schema master role, untill eventually the hard disk crashed and i was forced to seize the Shema master role.

Open a remote desktop connect to a server (does not need to be a DC), and open the command prompt.

Type to followuing:

NTDSUTIL

Roles -lets you manage FSMO roles, this way you can transfer them or seize them.

Conections -You need to connect to the DC where you want to move or seize the roles to.
Even if you are logged on to the dc where you want to move the roles to, you still need to make the connection.

Connect to server %Servername% -If successfully you will see that you are connect to the DC with logged on credentials. So make sure that the account used has enough rights to manage these roles.

Quit -Which returns you to the Roles menu.

Seize Schema Master -Now a warning is displayed, asking you if you are sure to move the Schema master rules to the connected DC. Seizing roles should only be performed as a last option.
In my case i got an access denied. Checked my account and saw it was not part of the Schema admin group. Added myself and tried again. Which failed again. Descided to relog as it could be that the Session granting ticket needed to be renewed. After relogging, i was able to successfully seize the schema master to the conected domain controller.











The red part shows you that NTDSUTIL will first try to move the role, before eventually seizing the role.
the blue part shows all the knows (belonging) roles on the connected domaion controller.
Which was all 5 in my case. Remember that the server where you seized the roles from, can never be brought online again. If for some miraclous reason the disk would turn up oke, you'll need to format that disk and install a fresh OS.

(AD) GPO's in Windows Server 2008 (Beta)

I had some time today, and went to search for group policies in Windows Server 2008.
And I must say it was a big search!

I wondered if the group management console was installed by default, so I tried to open it through typing gpmc.msc in the run command. But no luck, although I presumed it was installed by default, the command wasn’t recognized.
Opened dsa.msc (users and computers GUI) through the run command and right clicked the domain...Nothing?!...Strange...Right clicked an OU (no not an container) and still nothing?!
Damn, what am I missing? Oke... I might need to enable the advanced view to be able to see the GPO tab, but still no luck after enabling the advanced view options.

It hurts my ego, but I’ll have to use the help function to find out what has changed. Pressed F1, and typed GPO in the search field. The first link in the query seems to be the right one, and it says (I quote) "To link a new GPO, right click the domain or OU within a domain, and than click Create a GPO in this domain, and link it here. In the name box, type the name for the new GPO and than click OK."
Oké, that pretty obvious, have I missed that?! Checked again, and hell noooooo, I did not. It isn't there :(.....

Well lets try to install GPMC.MSI and see if I could find my way around than. Downloaded GPMC.msi and opened it. GPMC.msi ends with saying "set-up can not complete because Microsoft .net frameworks is not installed on your system." Aaah damn, oh well no problem, downloaded the redistributable package and opened it...
"This Package could not be installed, because its already installed on your computer"

That's it! Let’s call in the help of my good friend, Mr Google!

Well after googling around for one hour, I started to put ‘a’ and ‘b’ together which pointed me in the wright direction (might missed the obvious, sorry if I did). So for all of you who are still searching, here it goes:

Group Policy Management Console is shipped with Windows Server 2008 (Beta) but isn't installed. To enable it and install it you need to type "servermanagercmd -install gpmc" in the run command (not the command prompt). After running that command you'll find group policy management back in the administrative tools.

Shortly after opening the gpmc you'll find that GPMC can't read the default domain & domain controller policy. As you might know, new policies are XML based and have the ADMX extension instead of the ADM extension, which is probably causing GPMC to display the error. I'll look into it, but that's food for another thread later on.

(AD) Setting DNS suffix through GPO

When you add multiple groups or members in AD you use ';' to sepperate them.
When you use ';' to sepperate the DNS suffixes in the GPO your computer will have problems with DNS resolving. The correct format for DNS suffixes is "CSV", so you have to use ',' to sepperate your DNS suffixes.

If you have used ';' like i did, you will see that when you try to ping, the computer automatically adds a dot '.' at the end of the hostname. It does this also when resolving RDN's, making it impossible to resolve. This problems isn't salvagable when it occurs, because the registry shows the correct vallue's (HLKM\CurrentControlSet\Services\TcpIp\Parameters).

Restoring the system state however seems to be the only sollution.