Configure the WSUS Server

May 16th, 2008 by shiraj

Configure the WSUS Server and Create Computer Groups for Computers

Next, you configure WSUS for synchronization and approving updates by using the Administrator Console interface and then modifying Group Policy settings in Active Directory.

Modify Synchronization Settings

In this section you synchronize your server with the Microsoft Windows Update servers.

Procedure UM.5: To configure the WSUS server

1. Open up the Windows Server Update Services Deployment Guide downloaded in Install WSUS.
2. From the Table of Contents, navigate to Configure the WSUS Server to learn about the process of configuring WSUS.
3. Perform the following procedures:  

• Access the WSUS Administration Console
• Configure WSUS to Use a Proxy Server
• Select Products and Classifications
• Synchronize the WSUS Server
• Configure Advanced Synchronization Options
• Chain WSUS Servers Together
• Create a Replica Group
• Create Computer Groups for Computers
• Approve Updates

Create a Group Policy for Update Management

This procedure allows you to use Group Policy to manage software updates.

First, add the WSUS Group Policy.

Procedure UM.6: To add the Windows Server Update Services Group Policy

1. Log on to AD01 using an account that is a member of the Domain Administrators group.
2. Click Start, click Administrative Tools, and then click Group Policy Management.
3. Expand Domains, and then expand your domain (for example, fabrikam.com).
4. Expand Group Policy Objects.
5. Right-click Group Policy Objects, and then select New.
6. Type a name for the GPO (for example, Windows Server Update Services), and then click OK.

Import the Security Template into the New GPO

You will need the WUAU.adm file that describes the new policy settings for the Automatic Updates client. WUAU.adm is automatically installed into the %windir%\inf folder when you install Automatic Updates.

Procedure UM.7: To import the security template into the new GPO

1. Right-click the newly created Windows Server Update Services GPO, and then click Edit.
2. From the Deploying Microsoft Windows Server Update Services document, perform the steps from the Update and Configure the Automatic Updates Client Compoment section to configure the following procedures:  

• To add the WSUS Administrative Template
• To configure the behavior of Automatic Updates
• To redirect Automatic Updates to a WSUS server  

In step 3, enter http://wsus01 for the server name.
• To enable client-side targeting  

In step 3, type the group name created earlier (Hosting Servers) in the box.
3. Close the Group Policy Object Editor.

Apply the GPO to an Active Directory OU

Finally, apply the Windows Server Update Services settings to all domain servers by linking the GPO to the Servers OU. Once all servers obtain the policy information from the domain controller, they will then check for and install updates from WSUS01 based on the configurations.

Procedure UM.8: To apply the GPO to the Servers OU

1. Open the Group Policy Management Console.
2. Expand Domains, and then expand your domain (for example, fabrikam.com).
3. Expand Group Policy Objects.
4. Click the previously created Windows Server Update Services GPO, and then drag it onto the Servers OU, to which it should be linked.
5. In the Group Policy Management dialog box, click OK to confirm the creation of the GPO link.
6. Click the previously created Windows Server Update Services GPO and drag it onto the Domain Controllers OU, to which it should be linked.
7. In the Group Policy Management dialog box, click OK to confirm the creation of the GPO link.

Find hidden network adapter in Device Manager

May 10th, 2008 by shiraj

Error message when you try to set an IP address on a network adapter.
When you trying to set the IP address on a network adapter, you may receive the following error message:

The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter Name of adapter. Name of adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. If the same address is assigned to both adapters and they become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the advanced dialog box?

CAUSE

A network adapter with the same IP address is in the registry but is hidden in Device Manager. This can occur when you move a network card from one PCI slot to another PCI slot.

Back to the top

RESOLUTION

To resolve this problem, uninstall the ghosted network adapter from the registry using one of the following methods:

Back to the top

Method 1

1. Click Start, click Run, type cmd.exe, and then press ENTER.
2. Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
3. Type Start DEVMGMT.MSC, and then press ENTER.
4. Click View, and then click Show Hidden Devices.
5. Expand the Network Adapters tree.
6. Right-click the dimmed network adapter, and then click Uninstall.

Back to the top

Method 2

The DevCon utility is a command-line utility that acts as an alternative to Device Manager. When you use DevCon, you can enable, disable, restart, update, remove, and query individual devices or groups of devices. To use DevCon, follow these steps:

1. Download the DevCon tool by clicking the following article number to view the article in the Microsoft Knowledge Base:

311272 (http://support.microsoft.com/kb/311272/) The DevCon command-line utility functions as an alternative to Device Manager
2. Unpack the 32-bit or 64-bit DevCon tool binary to a local folder.
3. Click Start, click Run, then type cmd and press ENTER.
4. Type CD:\path_to_binaries to navigate to the devcon.exe is located.
5. Use the following syntax to find installed network adapters:
devcon findall =net or
devcon listclass net
Note In the output of the previous commands, there is a line for the ghosted network adapter that is similar to the following:

PCI\VEN_10B7&DEV_9200&SUBSYS_00D81028&REV_78\4&19FD8D60&0&58F0: 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible)
6. Remove the ghosted device by typing the following syntax:

devcon -r remove “@PCI\VEN_10B7&DEV_9200&SUBSYS_00D81028&REV_78\4&19FD8D60&0&58F0“

upgrading 2000 dc with exchange 2000 to 2003

May 3rd, 2008 by shiraj

http://support.microsoft.com/kb/325379
How to upgrade Windows 2000 domain controllers to Windows Server 2003

Microsoft Exchange 2000 in Windows 2000 forests

Notes

• If Exchange 2000 Server is installed, or will be installed, in a Windows 2000 forest, read this section before you run the Windows Server 2003 adprep /forestprep command.
• If Microsoft Exchange Server 2003 schema changes will be installed, go to the “Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003” section before you run the Windows Server 2003 adprep commands.

The Exchange 2000 schema defines three inetOrgPerson attributes with non-Request for Comment (RFC)-compliant LDAPDisplayNames: houseIdentifier, secretary, and labeledURI.

The Windows 2000 inetOrgPerson Kit and the Windows Server 2003 adprep command define RFC-complaint versions of the same three attributes with identical LDAPDisplayNames as the non-RFC-compliant versions.

When the Windows Server 2003 adprep /forestprep command is run without corrective scripts in a forest that contains Windows 2000 and Exchange 2000 schema changes, the LDAPDisplayNames for the houseIdentifier, labeledURI, and secretary attributes become mangled. An attribute becomes “mangled” if “Dup” or other unique characters are added to the beginning of the conflicted attribute name so that objects and attributes in the directory have unique names.

Active Directory forests are not vulnerable to mangled LDAPDisplayNames for these attributes in the following cases:

• If you run the Windows Server 2003 adprep /forestprep command in a forest that contains the Windows 2000 schema before you add the Exchange 2000 schema.
• If you install the Exchange 2000 schema in forest that was created where a Windows Server 2003 domain controller was the first domain controller in the forest.
• If you add Windows 2000 inetOrgPerson Kit to a forest that contains the Windows 2000 schema, and then you install Exchange 2000 schema changes, and then you run the Windows Server 2003 adprep /forestprep command.
• If you add Exchange 2000 schema to an existing Windows 2000 forest, then run Exchange 2003 /forestprep before you run the Windows Server 2003 adprep /forestprep command.

Mangled attributes will occur in Windows 2000 in the following cases:

• If you add the Exchange 2000 versions of the labeledURI, the houseIdentifier, and the secretary attributes to a Windows 2000 forest before you install the Windows 2000 inetOrgPerson Kit.
• You add the Exchange 2000 versions of the labeledURI, the houseIdentifier, and the secretary attributes to a Windows 2000 forest before you run the Windows Server 2003 adprep /forestprep command without first running the cleanup scripts.

Action plans for each scenario follow:

Scenario 1: Exchange 2000 schema changes are added after you run the Windows Server 2003 adprep /forestprep command

If Exchange 2000 schema changes will be introduced to your Windows 2000 forest after the Windows Server 2003 adprep /forestprep command is run, no cleanup is required. Go to the “Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003

” section.

Scenario 2: Exchange 2000 schema changes will be installed before the Windows Server 2003 adprep /forestprep command

If Exchange 2000 schema changes have already been installed but you have NOT run the Windows Server 2003 adprep /forestprep command, consider the following action plan:

1. Log on to the console of the schema operations master by using an account that is a member of the Schema Admins security group.
2. Click Start, click Run, type notepad.exe in the Open box, and then click OK.
3. Copy the following text including the trailing hyphen after “schemaUpdateNow: 1″ to Notepad.

dn: CN=ms-Exch-Assistant-Name,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace:LDAPDisplayName
LDAPDisplayName: msExchAssistantName
-

dn: CN=ms-Exch-LabeledURI,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchLabeledURI
-

dn: CN=ms-Exch-House-Identifier,CN=Schema,CN=Configuration,DC=X
changetype: Modify
replace: LDAPDisplayName
LDAPDisplayName: msExchHouseIdentifier
-

dn:
changetype: Modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

4. Confirm that there is no space at the end of each line.
5. On the File menu, click Save. In the Save As dialog box, follow these steps:

a. In the File name box, type the following:

\%userprofile%\InetOrgPersonPrevent.ldf
b. In the Save as type box, click All Files.
c. In the Encoding box, click Unicode.
d. Click Save.
e. Quit Notepad.
6. Run the InetOrgPersonPrevent.ldf script.

a. Click Start, click Run, type cmd in the Open box, and then click OK.
b. At a command prompt, type the following, and then press ENTER:

cd %userprofile%
c. Type the following command

c:\documents and settings\%username%>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X “domain name path for forest root domain“

Syntax notes:

• DC=X is a case-sensitive constant.
• The domain name path for the root domain must be enclosed in quotation marks.

For example, the command syntax for an Active Directory forest whose forest root domain is TAILSPINTOYS.COM would be:

c:\documents and settings\administrator>ldifde -i -f inetorgpersonprevent.ldf -v -c DC=X “dc=tailspintoys,dc=com”

Note You may need to change the Schema Update Allowed registry subkey if you receive the following error message:

Schema update is not allowed on this DC because the registry key is not set or the DC is not the schema FSMO Role Owner.

For more information about how to change this registry subkey, click the following article number to view the article in the Microsoft Knowledge Base:

285172 (http://support.microsoft.com/kb/285172/) Schema update require Write access to schema in Active Directory
7. Verify that the LDAPDisplayNames for the CN=ms-Exch-Assistant-Name, CN=ms-Exch-LabeledURI, and CN=ms-Exch-House-Identifier attributes in the schema naming context now appear as msExchAssistantName, msExchLabeledURI, and msExchHouseIdentifier before you run the Windows Server 2003 adprep /forestprep commands.
8. Go to the “Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003 ” section to run the adprep /forestprep and /domainprep commands.

Scenario 3: The Windows Server 2003 forestprep command was run without first running inetOrgPersonFix

If you run the Windows Server 2003 adprep /forestprep command in a Windows 2000 forest that contains the Exchange 2000 schema changes, the LDAPDisplayName attributes for houseIdentifier, secretary, and labeledURI will become mangled. To identify mangled names, use Ldp.exe to locate the affected attributes:

1. Install Ldp.exe from the Support\Tools folder of the Microsoft Windows 2000 or Windows Server 2003 media.
2. Start Ldp.exe from a domain controller or member computer in the forest.

a. On the Connection menu, click Connect, leave the Server box empty, type 389 in the Port box, and then click OK.
b. On the Connection menu, click Bind, leave all the boxes empty, and then click OK.
3. Record the distinguished name path for the SchemaNamingContext attribute. For example, for a domain controller in the CORP.ADATUM.COM forest, the distinguished name path might be CN=Schema,CN=Configuration,DC=corp,DC=company,DC=com.
4. On the Browse menu, click Search.
5. Use the following settings to configure the Search dialog box:

• Base DN: The distinguished name path for the schema naming context that is identified in step 3.
• Filter: (ldapdisplayname=dup*)
• Scope: Subtree
6. Mangled houseIdentifier, secretary, and labeledURI attributes have LDAPDisplayName attributes that are similar to the following format:

LDAPDisplayName: DUP-labeledURI-9591bbd3-d2a6-4669-afda-48af7c35507d;
LDAPDisplayName: DUP-secretary-c5a1240d-70c0-455c-9906-a4070602f85f
LDAPDisplayName: DUP-houseIdentifier-354b0ca8-9b6c-4722-aae7-e66906cc9eef
7. If the LDAPDisplayNames for labeledURI, secretary, and houseIdentifier were mangled in step 6, run the Windows Server 2003 InetOrgPersonFix.ldf script to recover, and then go to the “Upgrading Windows 2000 domain controllers with Winnt32.exe” section.

a. Create a folder named %Systemdrive%\IOP, and then extract the InetOrgPersonFix.ldf file to this folder.
b. At a command prompt, type cd %systemdrive%\iop.
c. Extract the InetOrgPersonFix.ldf file from the Support.cab file that is located in the Support\Tools folder of the Windows Server 2003 installation media.
d. From the console of the schema operations master, load the InetOrgPersonFix.ldf file by using Ldifde.exe to correct the LdapDisplayName attribute of the houseIdentifier, secretary, and labeledURI attributes. To do so, type the following command, where <X> is a case-sensitive constant and <dn path for forest root domain> is the domain name path for the root domain of the forest:

C:\IOP>ldifde -i -f inetorgpersonfix.ldf -v -c DC=X “domain name path for forest root domain“

Syntax notes:

• DC=X is a case-sensitive constant.
• The domain name path for the forest root domain must be enclosed in quotation marks.
8. Verify that the houseIdentifier, secretary, and labeledURI attributes in the schema naming context are not “mangled” before you install Exchange 2000.

For more information about a related schema conflict with Services for UNIX version 2.0, click the following article number to view the article in the Microsoft Knowledge Base:

293783 (http://support.microsoft.com/kb/293783/) Cannot upgrade Windows 2000 server to Windows Server 2003 with Windows Services for UNIX 2.0 installed

Back to the top

Overview: Upgrading Windows 2000 domain controllers to Windows Server 2003

The Windows Server 2003 adprep command that you run from the \I386 folder of the Windows Server 2003 media prepares a Windows 2000 forest and its domains for the addition of Windows Server 2003 domain controllers. The Windows Server 2003 adprep /forestprep command adds the following features:

• Improved default security descriptors for object classes
• New user and group attributes
• New Schema objects and attributes like inetOrgPerson

The adprep utility supports two command-line arguments:

adprep /forestprep: Runs forest upgrade operations.
adprep /domainprep: Runs domain upgrade operations.

The adprep /forestprep command is a one-time operation performed on the schema operation master (FSMO) of the forest. The forestprep operation must complete and replicate to the infrastructure master of each domain before you can run adprep /domainprep in that domain.

The adprep /domainprep command is a one-time operation that you run on the infrastructure operations master domain controller of each domain in the forest that will host new or upgraded Windows Server 2003 domain controllers. The adprep /domainprep command verifies that the changes from forestprep have replicated in the domain partition and then makes its own changes to the domain partition and group policies in the Sysvol share.

You cannot perform either of the following actions unless the /forestprep and the /domainprep operations have completed and replicated to all the domain controllers in that domain:

• Upgrade the Windows 2000 domain controllers to Windows Server 2003 domain controllers by using Winnt32.exe.

Note: You can upgrade the Windows 2000 member servers and computers to Windows Server 2003 member computers whenever you want.
• Promote new Windows Server 2003 domain controllers into the domain by using Dcpromo.exe.

The domain that hosts the schema operations master is the only domain where you must run both adprep /forestprep and adprep /domainprep. In all other domains, you only have to run adprep /domainprep.

The adprep /forestprep and the adprep /domainprep commands do not add attributes to the global catalog partial attribute set or cause a full synchronization of the global catalog. The RTM version of adprep /domainprep does cause a full sync of the \Policies folder in the Sysvol tree. Even if you run forestprep and domainprep several times, completed operations are performed only one time.

After the changes from adprep /forestprep and adprep /domainprep completely replicate, you can upgrade the Windows 2000 domain controllers to Windows Server 2003 by running Winnt32.exe from the \I386 folder of the Windows Server 2003 media. Also, you can add new Windows Server 2003 domain controllers to the domain by using Dcpromo.exe.

Upgrading the forest with the adprep /forestprep command

To prepare a Windows 2000 forest and domains to accept Windows Server 2003 domain controllers, follow these steps first in a lab environment, then in a production environment:

1. Make sure that you have completed all the operations in the “Forest Inventory” phase with special attention to the following items:

a. You have created system state backups.
b. All the Windows 2000 domain controllers in the forest have installed all the appropriate hotfixes and service packs.
c. End-to-end replication of Active Directory is occurring throughout the forest
d. FRS replicates the file system policy correctly throughout each domain.
2. Log on to the console of the schema operations master with an account that is a member of the Schema Admins security group.
3. Verify that the schema FSMO has performed inbound replication of the schema partition by typing the following at a Windows NT command prompt:

repadmin /showreps

(repadmin is installed by the Support\Tools folder of Active Directory.)
4. Early Microsoft documentation recommends that you isolate the schema operations master on a private network before you run adprep /forestprep. Real-world experience suggests that this step is not necessary and may cause a schema operations master to reject schema changes when it is restarted on a private network. If you want to isolate schema additions that were made by adprep, Microsoft recommends that you temporarily disable outbound replication of Active Directory with the repadmin command-line utility. To do this, following these steps:

a. Click Start, click Run, type cmd, and then click OK.
b. Type the following, and then press ENTER:

repadmin /options +DISABLE_OUTBOUND_REPL
5. Run adprep on the schema operations master. To do so, click Start, click Run, type cmd, and then click OK. On the schema operations master, type the following command

X:\I386\adprep /forestprep

where X:\I386\ is the path of the Windows Server 2003 installation media. This command runs the forest-wide schema upgrade.

Note Events with event ID 1153 that are logged in the Directory Service event log, such as the sample that follows, can be ignored:

Event Type : Error
Event Source : NTDS General
Event Category: Internal Processing
Event ID : 1153
Date: MM/DD/YYYY
Time: HH:MM:SS AM|PM
User : Everyone Computer : <some DC>
Description: Class identifier 655562 (class name msWMI-MergeablePolicyTemplate) has an invalid superclass 655560. Inheritance ignored.
6. Verify that the adprep /forestprep command successfully ran on the schema operations master. To do so, from the console of the schema operations master, verify the following items:

• The adprep /forestprep command completed without error.
• The CN=Windows2003Update object is written under CN=ForestUpdates,CN=Configuration,DC=forest_root_domain. Record the value of the Revision attribute.
• (Optional) The schema version incremented to version 30. To do so, see the ObjectVersion attribute under CN=Schema,CN=Configuration,DC=forest_root_domain.

If adprep /forestprep does not run, verify the following items:

• The fully qualified path for Adprep.exe located in the \I386 folder of the installation media was specified when adprep ran. To do so, type the following command:

x:\i386\adprep /forestprep

where x is the drive that hosts the installation media.
• The logged on user who runs adprep has membership to the Schema Admins security group. To verify this, use the whoami /all command.
• If adprep still does not work, view the Adprep.log file in the %systemroot%\System32\Debug\Adprep\Logs\Latest_log folder.
7. If you disabled outbound replication on the schema operations master in step 4, enable replication so that the schema changes that were made by adprep /forestprep can propagate. To do this, following these steps:

a. Click Start, click Run, type cmd, and then click OK.
b. Type the following, and then press ENTER:

repadmin /options -DISABLE_OUTBOUND_REPL
8. Verify that the adprep /forestprep changes have replicated on all the domain controllers in the forest. It is useful to monitor the following attributes:

a. Incrementing the schema version
b. The CN=Windows2003Update, CN=ForestUpdates,CN=Configuration,DC=forest_root_domain or CN=Operations,CN=DomainUpdates,CN=System,DC=forest_root_domain and the operations GUIDs under it have replicated in.
c. Search for new schema classes, objects, attributes, or other changes that adprep /forestprep adds, such as inetOrgPerson. View the SchXX.ldf files (where XX is a number between 14 and 30) in the %systemroot%\System32 folder to determine what objects and attributes there should be. For example, inetOrgPerson is defined in Sch18.ldf.
9. Look for mangled LDAPDisplayNames.

If Exchange 2000 was installed before you ran the Windows Server 2003 adprep /forestprep command, see the following article in the Microsoft Knowledge Base:

314649 (http://support.microsoft.com/kb/314649/) Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers

If you find mangled names, go to Scenario 3 of the same article.
10. Log on to the console of the schema operations master with an account that is a member of the Schema Admins group security group of the forest that hosts the schema operations master.

Upgrading the domain with the adprep /domainprep command

Run adprep /domainprep after the /forestprep changes fully replicate to the infrastructure master domain controller in each domain that will host Windows Server 2003 domain controllers. To do so, follow these steps:

1. Identify the infrastructure master domain controller in the domain you are upgrading, and then log on with an account that is a member of the Domain Admins security group in the domain you are upgrading.

Note: The enterprise administrator may not be a member of the Domain Admins security group in child domains of the forest.
2. Run adprep /domainprep on the Infrastructure master. To do so, click Start, click Run, type cmd, and then on the Infrastructure master type the following command:

X:\I386\adprep /domainprep

where X:\I386\ is the path of the Windows Server 2003 installation media. This command runs domain-wide changes in the target domain.

Note: The adprep /domainprep command modifies files permissions in the Sysvol share. These modifications cause a full synchronization of files in that directory tree.
3. Verify that domainprep completed successfully. To do so, verify the following items:

• The adprep /domainprep command completed without error.
• The CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=dn path of domain you are upgrading exists

If adprep /domainprep does not run, verify the following items:

• The logged on user who runs adprep has membership to the Domain Admins security group in the domain being you are upgrading. To do so, use the whoami /all command.
• The fully qualified path for Adprep.exe located in the \I386 directory of the installation media was specified when you ran adprep. To do so, at a command prompt type the following command:

x:\i386\adprep /forestprep

where x is the drive that hosts the installation media.
• If adprep still does not work, view the Adprep.log file in the %systemroot%\System32\Debug\Adprep\Logs\Latest_log folder.
4. Verify that the adprep /domainprep changes have replicated. To do so, for the remaining domain controllers in the domain, verify the following items:

• The CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=dn path of domain you are upgrading object exists and the value for the Revision attribute matches the value of the same attribute on the infrastructure master of the domain.
• (Optional) Look for objects, attributes or access control list (ACL) changes that adprep /domainprep added.

Repeat steps 1-4 on the infrastructure master of the remaining domains in bulk or as you add or upgrade DC’s in those domains to Windows Server 2003. Now you can promote new Windows Server 2003 computers into the forest by using DCPROMO. Or, you can upgrade existing Windows 2000 domain controllers to Windows Server 2003 by using WINNT32.EXE.

Linux Newbie Administrtor Guide

May 2nd, 2008 by shiraj

http://linux-newbie.sunsite.dk/

LINUX NEWBIE ADMINISTRATOR GUIDE