Windows 2008 Server R2 adprep\adprep32

Are you having trouble running ADPREP on your current 32-bit Domain Controller? Have you ran ADPREP multiple times on your Domain but still get an error stating you have not prepared your Domain yet?

Here is a change that gets even the most seasoned Admins. In Windows 2008 Server R2 there is a new ADPREP that needs to be run on a Domain Controller that are your FSMO role holder of the Schema Master role and run a 32-bit version of Windows Server. 

The Domain prep tool is called ADPREP32 which is located on in the \support\adprep.

The switches for the ADPREP32 are the same as the adprep. Here are the main switches used /FORESTPREP, /DOMAINPREP, and /RODCPREP.

Now adprep is still used when your current Domain Controller that holds the FSMO role of Schema Master role is running a 64-bit version of Windows Server. Actually the 64-bit version of ADPREP runs by default this is why you must know to run ADPREP32 on your 32-bit Domain Controller. 

Some background information on adprep:

ADPREP is a command line tool that comes with each version of Windows server.  ADPREP is used to extend the Active Directory schema to support the new features of Active Directory Services in the new Windows version.

There are a number of switches that need to be used with the ADPREP command depending on the version of Windows and the current Domain/Forest structure. 

ADPREP updates the Active Directory schema; updates security descriptors; modifies ACLs for Active Directory objects & SYSVOL; and sometimes creates new objects and containers.


Here are the Active Directory schema versions:

13=Windows 2000
30=windows 2003
31=Windows 2003 R2
44=Windows 2008
47=Windows 2008 R2

All about Permissions:NTFS and Share

Share vs. NTFS

Share permissions are the permissions you set for a folder when you share that folder. The share permissions determine the type of access others have to the shared folder across the network. There are three types of share permissions: Full Control, Change, and Read.

NTFS permissions determine the action users can take for a folder or file both across the network and locally. Unlike share permissions, NTFS permissions offer several other permissions besides Full Control, Change, and Read that can be set for groups or individually. The most restrictive permission applies when share and NTFS permissions conflict.

As you get deeper into creating shares and applying NTFS permissions to various assets, you’ll eventually run into a problem: What happens when you combine share and NTFS permissions?

For example, suppose you’ve shared a folder on a Windows Server 2012 system and you’ve created the share as a read-only share for the Everyone group, but the NTFS permissions for the folder are Full Control for the Everyone group. When conflicts like this arise between share and NTFS permissions, the most restrictive permission set wins out. So, in this example, the share’s read-only permission would win the day and users would be unable to make changes to files and folders inside the share.

Likewise, if the share permissions granted the Everyone group Full Control, but the NTFS permissions were Read, the NTFS permissions would win because they’re the most restrictive.

Keep in mind that NTFS vs. NTFS permissions are additive. So, if user A has been granted NTFS Read rights and a group to which user A belongs has been granted NTFS Modify rights, then user A gets both Read and Modify rights. However, once share permissions enter the equation, things are a bit different.

Another point to note: Share permissions are only enforced if the contents of the shared folder are accessed over the network. If a user manages to log in directly to a server and access the folder through the file system on the local server, only the NTFS permissions will apply.

Explicit vs. Inherited Permissions

Each permission that exists can be assigned one of two ways: explicitly or by inheritance. For this reason, permissions are referred to as explicit permissions and inherited permissions.

• Explicit permissions are permissions that are set by default when the object is created, or by user action.

• Inherited permissions are permissions that are given to an object because it is a child of a parent object.

Similar to the way rights are managed for groups of users, permissions are best managed for containers of objects. Objects within the container inherit all the access permissions in that container.

For example, you might explicitly give permissions to a folder named MyFolder. All subfolders created within MyFolder automatically inherit the permissions assigned to MyFolder.

In the example above, it is possible to stop subfolders from inheriting access permissions. To do this, you must explicitly clear a setting that causes the inheritance.

Allow vs. Deny Permissions

When establishing permissions, you need to specify whether the entry should have access (Allow) or not have access (not Allow) to the resource.

After permissions have been set, the LSASS (Local Security Authority) controls access to the resource. LSASS compares the SID (Security ID) that you placed on the ACL (Access Control List) with the SID placed on the security access token that is given to the user at logon. If the SID associated with the user is on the ACL, the LSASS must determine whether the access is set to Allow or Deny. The Allow and Deny permissions inherit down through the structure.

Use the Deny permission sparingly, because of the fact that restrictive permissions override lenient permissions. It is more common to clear all the Allow check box for a group, thereby removing the group from the ACL.

This has the same result, giving no access to the resource. “Not-Allow” access in this way is easier to troubleshoot, manage and configure. It is easy to forget that you have used the Deny option.

You deny permissions (using explicit Deny) only to a specific user when it is necessary to override permissions that are otherwise allowed for the group to which this user belongs.

Permission Precedence

Because of the fact that users have can have many different rights settings and objects can have many different permission settings, it is possible that conflicting permission settings might apply to a particular object and access method.

When this occurs, the system must engage in a process of resolving the various permissions to determine which ones should govern the access.

Here are some rules for resolving permissions conflicts:

1. “Deny” permissions generally take precedence over “allow” permissions.

2. Permissions applied directly to an object (explicit permissions) take precedence over permissions inherited from a parent (for example from a group).

3. Permissions inherited from near relatives take precedence over permissions inherited from distant predecessors. So permissions inherited from the object’s parent folder take precedence over permissions inherited from the object’s “grandparent” folder, and so on.

4. Permissions from different user groups that are at the same level (in terms of being directly-set or inherited, and in terms of being “deny” or “allow”) are cumulative. So if a user is a member of two groups, one of which has an “allow” permission of “Read” and the other has an “allow” of “Write”, the user will have both read and write permission–depending on the other rules above, of course.

Although Deny permissions generally take precedence over allow permissions, this is not always the case. An explicit “allow” permission can take precedence over an inherited “deny” permission.

The hierarchy of precedence for the permissions can be summarized as follows, with the higher precedence permissions listed at the top of the list:

• Explicit Deny

• Explicit Allow

• Inherited Deny

• Inherited Allow

Get rid of second 169.254.x.x IPv4 address on Windows Server 2008 R2

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ there were two AdaptorGUIDs, but only one of them had any parameters.

I created the IPAutoConfigurationEnabled parameter for both these AdaptorGUIDs with a value of 0 as instructed and re-booted.

Here are the registry entries for the two AdaptorGUIDs:

Reboot and check.

Restoring the Default Domain and Default Domain Controller Policy in Windows Server 2008

It is Microsoft Best Practice to leave the Default Domain Policy alone – and create another Group Policy on domain level and define settings there. If you follow this Best Practice you surely have no problems when reverting your settings to the default. If you have changed the Default Domain Policy, you could run into pain what if you need to revert the settings you made?

C:\>dcgpofix /ignoreschema

Microsoft(R) Windows(R) Operating System Default Group Policy Restore Utility v5.1
Copyright (C) Microsoft Corporation. 1981-2003
Description: Recreates the Default Group Policy Objects (GPOs) for a domain
Syntax: DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

This utility can restore either or both the Default Domain Policy or the
Default Domain Controllers Policy to the state that exists immediately after
a clean install. You must be a domain administrator to perform this operation.

WARNING: YOU WILL LOSE ANY CHANGES YOU HAVE MADE TO THESE GPOs. THIS UTILITY IS INTENDED ONLY FOR DISASTER RECOVERY PURPOSES.

You are about to restore Default Domain policy  and Default domain Controller policy for the following domain

test.com

Do you want to continue: <Y/N>? y

WARNING: This operation will replace all ‘User Rights Assignments’ made in the chosen GPOs. This may render some server applications to fail. Do you want to continue: <Y/N>? y
The Default Domain Policy was restored successfully Note: Only the contents of the Default Domain Policy was restored. Group Policy links to this Group Policy Object were not altered.
By default, The Default Domain Policy is linked to the Domain.

The Default Domain Controller Policy was restored successfully Note: Only the contents of the Default Domain Controller Policy was restored. Group Policy links to this Group Policy Object were not altered. By default, The Default Domain Controller Policy is linked to the Domain Controllers OU.

How to find a Global Catalog server?

With DNS Requests (NSLOOKUP)

In an Active Directory environment, all Global Catalogs are anchored in DNS . There is a separate subdomain ‘GC._msdcs ….’ in the namespace of the AD root domain (please remember: the global catalog does not refer to individual domains, but to the entire forest). So if your root domain in the forest is e.g. contoso.com, then you get a list of all GCs with this command:

C:\> nslookup gc._msdcs.contoso.com

Server:  dc.contoso.com
Address:  10.10.67.250

Name:  gc._msdcs.contoso.com
Adresses:  10.10.67.250
10.10.67.251
10.10.67.252
10.10.67.253

The container _msdcs contains the infrastructural DNS records of the Active Directory. This is also where all the SRVservice records for the domain controllers are stored.

With DSQUERY

You can also use the standard command line tool DSQUERY for searching GCs. The search can be limited to certain domains or AD sites. However, you must be authenticated in the regarding forest and DSQUERY must be available on your machine (this is usually the case on Widows servers). As a result, the server objects in the Configuration partition is displayed:

C:\> dsquery server -isgc

“CN=DC,CN=Servers,CN=Site-Sidney,CN=Sites,CN=Configuration,DC=contoso,DC=com”
“CN=DC014,CN=Servers,CN=Site-Auckland,CN=Sites,CN=Configuration,DC=contoso,DC=com”

Remove Offline Domain Controller / Active Directory Metadata Cleanup

Metadata cleanup is a required procedure after a forced removal of Active Directory Domain Services (AD DS). You perform metadata cleanup on a domain controller in the domain of the domain controller that you forcibly removed. Metadata cleanup removes data from AD DS that identifies a domain controller to the replication system. Metadata cleanup also removes File Replication Service (FRS) and Distributed File System (DFS) Replication connections and attempts to transfer or seize any operations master (also known as flexible single master operations or FSMO) roles that the retired domain controller holds.

You can clean up server metadata by using the following:

When you use Remote Server Administration Tools (RSAT) or the Active Directory Users and Computers console (Dsa.msc) that is included with Windows Server 2008 or Windows Server 2008 R2 to delete a domain controller computer account from the Domain Controllers organizational unit (OU), the cleanup of server metadata is performed automatically. Previously, you had to perform a separate metadata cleanup procedure.

You can also use the Active Directory Sites and Services console (Dssite.msc) to delete a domain controller’s computer account, which also completes metadata cleanup automatically. However, Active Directory Sites and Services removes the metadata automatically only when you first delete the NTDS Settings object below the computer account in Dssite.msc.

As long as you are using the Windows Server 2008, Windows Server 2008 R2, or RSAT versions of Dsa.msc or Dssite.msc, you can clean up metadata automatically for domain controllers running earlier versions of Windows operating systems.

Membership in Domain Admins, or equivalent, is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

  1. Open Active Directory Users and Computers: On the Start menu, point to Administrative Tools, and then click Active Directory Users and Computers.
  2. If you have identified replication partners in preparation for this procedure and if you are not connected to a replication partner of the removed domain controller whose metadata you are cleaning up, right-click Active Directory Users and Computers <DomainControllerName>, and then click Change Domain Controller. Click the name of the domain controller from which you want to remove the metadata, and then click OK.
  3. Expand the domain of the domain controller that was forcibly removed, and then click Domain Controllers.
  4. In the details pane, right-click the computer object of the domain controller whose metadata you want to clean up, and then click Delete.

    Metadata Cleanup in ADUC

  5. In the Active Directory Domain Services dialog box, click Yes to confirm the computer object deletion.
  6. In the Deleting Domain Controller dialog box, select This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO), and then click Delete.

    DC offline in AD Users and Computers

  7. If the domain controller is a global catalog server, in the Delete Domain Controller dialog box, click Yes to continue with the deletion.
  8. If the domain controller currently holds one or more operations master roles, click OK to move the role or roles to the domain controller that is shown.

    You cannot change this domain controller. If you want to move the role to a different domain controller, you must move the role after you complete the server metadata cleanup procedure.

 

  1. Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services.
  2. If you have identified replication partners in preparation for this procedure and if you are not connected to a replication partner of the removed domain controller whose metadata you are cleaning up, right-click Active Directory Users and Computers <DomainControllerName>, and then click Change Domain Controller. Click the name of the domain controller from which you want to remove the metadata, and then click OK.
  3. Expand the site of the domain controller that was forcibly removed, expand Servers, expand the name of the domain controller, right-click the NTDS Settings object, and then click Delete.

    Metadata Cleanup in AD Sites and Services

  4. In the Active Directory Domain Services dialog box, click Yes to confirm the NTDS Settings deletion.
  5. In the Deleting Domain Controller dialog box, select This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO), and then click Delete.

    DC offline in AD Users and Computers

  6. If the domain controller is a global catalog server, in the Delete Domain Controller dialog box, click Yes to continue with the deletion.
  7. If the domain controller currently holds one or more operations master roles, click OK to move the role or roles to the domain controller that is shown.
  8. Right-click the domain controller that was forcibly removed, and then click Delete.

    DC Deletion in AD Sites and Services

  9. In the Active Directory Domain Services dialog box, click Yes to confirm the domain controller deletion.

As an alternative, you can clean up metadata by using Ntdsutil.exe, a command-line tool that is installed automatically on all domain controllers and servers that have Active Directory Lightweight Directory Services (AD LDS) installed. Ntdsutil.exe is also available on computers that have RSAT installed.

  1. Open a command prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Enterprise Admins credentials, if required, and then click Continue.
  2. At the command prompt, type the following command, and then press ENTER:

    ntdsutil

  3. At the ntdsutil: prompt, type the following command, and then press ENTER:

    metadata cleanup

  4. At the metadata cleanup: prompt, type the following command, and then press ENTER:

    remove selected server <ServerName>

    Or

    remove selected server <ServerName1> on <ServerName2>5.In Server Remove Configuration Dialog, review the information and warning, and then click Yes to remove the server object and metadata.

  5. At this point, Ntdsutil confirms that the domain controller was removed successfully. If you receive an error message that indicates that the object cannot be found, the domain controller might have been removed earlier.

    6.At the metadata cleanup: and ntdsutil: prompts, type quit, and then press ENTER.

    7.To confirm removal of the domain controller:

    Open Active Directory Users and Computers. In the domain of the removed domain controller, click Domain Controllers. In the details pane, an object for the domain controller that you removed should not appear.

    Open Active Directory Sites and Services. Navigate to the Servers container and confirm that the server object for the domain controller that you removed does not contain an NTDS Settings object. If no child objects appear below the server object, you can delete the server object. If a child object appears, do not delete the server object because another application is using the object.

Step-by-Step Guide to Fine-Grained Passwords in Windows Server 2008

I find it’s best to work with an example to demonstrate a solution, so in this case we will assume that you have a number of users who are Special Administrators and require a stronger password group policy than the standard user.  We will refer to these users as SpecialAdmins

In the following steps, we will configure a fine-grained password policy in Windows Server 2008 with the following settings:

Policy Name Policy Setting
Enforce password history 24 passwords remembered
Maximum password age 30 days
Minimum password age 1 day
Minimum password length 12 characters
Passwords must meet complexity requirements Disabled
Account lockout duration 0
Account lockout threshold 3
Reset account lockout counter after 30 minutes

Table 1: Password Policy

Note: yourdomainname in the following steps should be replaced with the NETBIOS name of your domain.

  1. Logon to a Windows Server 2008 domain controller using an account that has membership in the Domain Admins group, or equivalent permissions.
  2. Go to Start, Administrative Tools, and then select Active Directory Users and ComputersActive Directory Users and Computers
  3. Expand yourdomainname.com, right-click on the Users container, select New, and then select Group.
  4. On the New Object – Group window, enter SpecialAdmins into the Group Name field, and then click OKNew Object - Group
  5. Close Active Directory Users and Computers
  6. Click Start, click RUN, type ADSIEDIT.MSC, and then click OK 

    adsiedit.msc

  7. In the ADSI Edit snap-in, right-click ADSI Edit, and then click Connect to
  8. In the Name field, enter yourdomainname.com, and then click OK
  9. Double-click yourdomainname.com in the console tree, double-click DC=yourdomainname,DC=com, double-click CN=System, and then click CN=Password Settings Container 

    CN=Password Settings Container

  10. Right-click CN=Password Settings Container in the console tree, click New, and then click ObjectPassword Settings Container - New Object
  11. In the Create Object dialog box, under Select a class, click msDC-PasswordSettings, and then click Next.Create Object - msDS-PasswordSettings
  12. In the Create Object dialog box, enter SpecialAdmins in the Value field, and then click Next.Create Object - msDS-PasswordSettings Value
  13. For the msDS-PasswordSettingsPrecedence value, enter 1, and then click NextmsDS-PasswordSettingsPrecedence
  14. For the msDS-PasswordReversibleEncryptionEnabled value, enter false, and then click NextmsDS-PasswordReversibleEncryptionEnabled
  15. For the msDS-PasswordHistoryLength value, enter 24, and then click NextmsDS-PasswordHistoryLength
  16. For the msDS-PasswordComplexityEnabled value, enter false, and then click NextmsDS-PasswordComplexityEnabled
  17. For the msDS-MinimumPasswordLength value, enter 12, and then click NextmsDS-MinimumPasswordLength
  18. For the msDS-MinimumPasswordAge, enter 1:00:00:00, and then click NextmsDS-MinimumPasswordAge
  19. For the msDS-MaximumPasswordAge, enter 30:00:00:00, and then click NextmsDS-MaximumPasswordAge
  20. For the msDS-LockoutThreshold, enter 3, and then click NextmsDS-LockoutThreshold
  21. For the msDS-LockoutObservationWindow, enter 0:00:30:00, and then click NextmsDS-LockoutObservationWindow
  22. For the msDS-LockoutDuration, enter (never), and then click Next, then click FinishmsDS-LockoutDuration
  23. Right-click on CN=SpecialAdmins in the console tree, and then select PropertiesmsDS-PasswordSettings Properties
  24. On the CN=SpecialAdmins Properties window, select the msDS-PSOAppliesTo attribute, and then click the Edit buttonmsDS-PSOAppliesTo
  25. On the Multi-valued Distinguished Name With Security Principal Editor window, click on the Add Windows Account buttonMulti-valued Distinguished Name With Security Principal Editor
  26. On the Select Users, Computers, or Groups window, enter SpecialAdmins in the Enter the object names to select field, and then click OKSelect Users, Computers, or Groups
  27. Click OK on the Multi-valued Distinguished Name With Security Principal Editor window
  28. Click OK on the CN=SpecialAdmins Properties windowmsDS-PSOAppliesToSetting

For More Reference:-

http://blogs.technet.com/b/seanearp/archive/2007/10/06/windows-server-2008-fine-grained-password-policy-walkthrough.aspx