Choose option

NITConnect Blog Home

Recent

What are the most common DNS related Dcpromo errors? How do I fix them?

July 13th, 2006

Problem
DNS related errors

Solution
Some common issues that you may encounter with Active Directory installation and configuration can cause a partial or complete loss of functionality in Active Directory. These issues may include, but not be limited to:

· Domain Name System (DNS) configuration errors.

· Network configuration problems
Difficulties when you upgrade from Microsoft Windows NT.

You must configure DNS correctly to ensure that Active Directory will function properly.

Daniel’s recommendations

If you are looking to really master Active Directory (or other Networking skills), I strongly recommend that you try Train Signal. I’ve discovered this company a few months ago and I always send people their way because the training is so good. You can see more HERE.

Daniel Petri

Review the following configuration items to ensure that DNS is healthy and that the Active Directory DNS entries will be registered correctly:

· DNS IP configuration

· Active Directory DNS registration

· Dynamic zone updates

· DNS forwarders

· DNS IP Configuration

An Active Directory server that is hosting DNS must have its TCP/IP settings configured properly. TCP/IP on an Active Directory DNS server must be configured to point to itself to allow the server to register with its own DNS server.

To view the current IP configuration
Open a command window and type

ipconfig /all

to display the details. You can modify the DNS configuration by following these steps:

1. Right-click My Network Places, and then click Properties.

2. Right-click Local Area Connection, and then click Properties.

3. Click Internet Protocol (TCP/IP), and then click Properties.

4. Click Advanced, and then click the DNS tab. Configure the DNS information as follows: Configure the DNS server addresses to point to the DNS server. This should be the computer’s own IP address if it is the first server or if no dedicated DNS server will be configured.

5. If the resolution of unqualified names setting is set to Append these DNS suffixes (in order), the Active Directory DNS domain name should be listed first (at the top of the list).

6. Verify that the DNS Suffix for this connection setting is the same as the Active Directory domain name.

7. Verify that the Register this connection’s addresses in DNS check box is selected.

8. At a command prompt, type

ipconfig /flushdns

to purge the DNS resolver cache, and then type

ipconfig /registerdns

to register the DNS resource records.

9. Start the DNS Management console. There should be a host record (an ‘A’ record in Advanced view) for the computer name. There should also be a Start of Authority (SOA in Advanced view) record pointing to the domain controller (DC) as well as a Name Server record (NS in Advanced view).

Active Directory DNS Registration
The Active Directory DNS records must be registering in DNS. The DNS zone can be either a standard primary or an Active Directory-integrated zone. An Active Directory-integrated zone is different from a standard primary zone in several ways. An Active Directory-integrated zone provides the following benefits:

· The Windows 2000 DNS service stores zone data in Active Directory. This causes DNS replication to create multiple masters, and it allows any DNS server to accept updates for a directory service-integrated zone. Using Active

· Directory integration also reduces the need to maintain a separate DNS zone transfer replication topology.

· Secure dynamic updates are integrated with Windows security. This allows an administrator to precisely control which computers can update which names, and it prevents unauthorized computers from obtaining existing names from DNS.

Use the following steps to ensure that DNS is registering the Active Directory DNS records:

1. Start the DNS Management console.

2. Expand the zone information under the server name.

3. Expand Forward Lookup Zones, right-click the name of the Active Directory domain’s DNS zone, click Properties, and then verify that Allow Dynamic Updates is set to Yes.

4. Four folders with the following names are present when DNS is correctly registering the Active Directory DNS records. These folders are labeled:

_msdcs
_sites
_tcp
_udp

If these folders do not exist, DNS is not registering the Active Directory DNS records. These records are critical to Active Directory functionality and must appear within the DNS zone. You should repair the Active Directory DNS record registration.

To repair the Active Directory DNS record registration
Check for the existence of a Root Zone entry. View the Forward Lookup zones in the DNS Management console.

There should be an entry for the domain. Other zone entries may exist. There should not be a dot (’.') zone. If the dot (’.') zone exists, delete the dot (’.') zone. The dot (’.') zone identifies the DNS server as a root server.

Typically, an Active Directory domain that needs external (Internet) access should not be configured as a root DNS server.

The server probably needs to reregister its IP configuration (by using Ipconfig) after you delete the dot (’.'). The Netlogon service may also need to be restarted.

Manually repopulate the Active Directory DNS entries. You can use the Windows 2000 Netdiag tool to repopulate the Active Directory DNS entries. Netdiag is included with the Windows 2000 Support tools. At a command prompt, type

netdiag /fix

After you run the Netdiag utility, refresh the view in the DNS Management console. The Active Directory DNS records should then be listed.

Note: The server may need to reregister its IP configuration (by using Ipconfig) after you run Netdiag. The Netlogon service may also need to be restarted.

If the Active Directory DNS records do not appear, you may need to manually re-create the DNS zone.

Manually re-create the DNS zone
1. Start the DNS Management console.

2. Right-click the name of the zone, and then click Delete.

3. Click OK to acknowledge any warnings. The Forward Lookup zones no longer list the deleted zone.

4. Right-click Forward Lookup Zones, and then click New Zone.

5. The New Zone Wizard starts. Click Next to continue.

6. Click the appropriate zone type (either Active Directory-integrated or Standard primary, and then click Next.

7. Type the name of the zone exactly as it appears in Network Identification, and then click Next.

8. Click the appropriate zone file, or a new zone file. Click Next, and then click Finish to finish the New Zone Wizard.

9. The newly created zone appears in the DNS Management console.

10. Right-click the newly created zone, click Properties, and then change Allow Dynamic Updates to Yes.

11. At a command prompt, type

net stop netlogon

and then press ENTER. The Netlogon service is stopped.

12. Type

net start netlogon

and then press ENTER. The Netlogon service is restarted.

13. Refresh the view in the DNS Management console. The Active Directory DNS records should be listed under the zone.

If the Active Directory DNS records still do not exist, there may be a disjointed DNS namespace.

Dynamic Zone Updates
Microsoft recommends that the DNS Lookup zone accept dynamic updates. You can configure this by right-clicking the name of the zone, and then clicking Properties. On the General tab, the Allow Updates setting should be set to Yes, or for an Active Directory-integrated zone, either Yes or Only secure updates. If dynamic updates are not allowed, all host registration must be completed manually.

DNS Forwarders
To ensure network functionality outside of the Active Directory domain (such as browser requests for Internet addresses), configure the DNS server to forward DNS requests to the appropriate Internet service provider (ISP) or corporate DNS servers.

See No Forwarding or Root Hints on Windows 2000 DNS server? for troubleshooting tips.

To configure forwarders on the DNS server:

1. Start the DNS Management console.

2. Right-click the name of the server, and then click Properties.

3. Click the Forwarders tab.

4. Click to select the Enable Forwarders check box.

Note: If the Enable Forwarders check box is unavailable, the DNS server is attempting to host a root zone (usually identified by a zone named only with a period, or dot (’.'). You must delete this zone to enable the DNS server to forward DNS requests. In a configuration in which the DNS server does not rely on an ISP DNS server or a corporate DNS server, you can use a root zone entry.

5. Type the appropriate IP addresses for the DNS servers that will accept forwarded requests from this DNS server. The list reads from the top down in order; if there is a preferred DNS server, place it at the top of the list.

6. Click OK to accept the changes.

Upgrade Installation Considerations
Earlier (Legacy) DNS Servers - DNS servers that run Windows NT 4.0 cannot dynamically register the Active Directory DNS records. The best solution in this case is to install DNS on the Active Directory domain controller to ensure that Active Directory DNS records will be registered for the domain.

Disjointed DNS Namespace - You must configure the correct DNS suffix information before you begin a Windows 2000 upgrade installation. You cannot change the server name and DNS domain information after Active Directory is installed.

To configure the DNS suffix information in Windows NT before you upgrade the computer to a Windows 2000-based Active Directory domain controller:

1. Right-click Network Neighborhood, and then click Properties.

2. Click the Protocols tab, click TCP/IP Protocol, and then click Properties.

3. Click the DNS tab.

4. In the Domain box, type the complete Active Directory domain name.

5. Click Apply, and then click OK.

6. Click OK to quit the Network tool.

7. Restart the computer.

To verify the settings, open a command window, and then type ipconfig /all. The Host Name line shows the fully qualified domain name.

If you must change the DNS domain information after you install Active Directory, you must run the Dcpromo utility on the computer to remove it from the domain and make it a stand-alone server.

To determine if a disjointed namespace exists on an existing Windows 2000-based domain controller:

1. Right-click My Computer, and then click Properties.

2. Click the Network Identification tab.

3. Compare the DNS suffix section of the full computer name to that of the domain name listing. The full computer name reads as follows: hostname. dns_suffix. These two entries should contain identical suffix information.

If these two entries do not contain identical suffix information, a disjointed DNS namespace exists. This condition prevents proper registration of any Active Directory DNS records.

Note: The only supported method to recover from a disjointed namespace is to use Dcpromo to remove the computer from the domain and make it a stand-alone server. You can then correct the DNS namespace information and run Dcpromo again to promote the computer back to a domain controller

Posted in Uncategorized, IT | No Comments »

event ID 8331 in Exchange Server 2003

July 13th, 2006

View products that this article applies to.

Article ID	:	837444
Last Review	:	June 24, 2004
Revision	:	1.0

SYMPTOMS

On a computer that is running Microsoft Exchange Server 2003 and that has more than one logical processor, you may find that Active Directory updates from Exchange 2003 no longer work correctly. The Recipient Update Service does not configure all the Exchange attributes for the user accounts. As a result, these users may not appear in the Global Address List or may not be able to connect to their Exchange mailboxes. Additionally, you may find that event ID 8331 error messages that are similar to the following are repeatedly logged to the application event log:

Type: Error
Source: MSExchangeAL
Category: Address List Synchronization
Event ID: 8331
Description:
The service threw an unexpected exception which was caught at Drive:\Titanium\Dsa\Src\Lra\Abv_dg\Lservagent.cpp(4511)

You may also receive event ID 8331 error messages that contain a description that reports than an unexpected exception occurred in the Active Directory Connector (Adc.exe) and in the Lotus Notes Dirsynch Connector component (Addxa.dll).

When you click Check Name while configuring Exchange e-mail accounts in Microsoft Outlook, you may receive an error message that is similar to the following:

The name could not be resolved. The name could not be matched to a name in the address list.

CAUSE

This problem may occur if an internal class incorrectly processes certain threads that run at the same time.

RESOLUTION

To resolve this problem, obtain the latest service pack for Exchange Server 2003. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

836993 (http://support.microsoft.com/kb/836993/) How to obtain the latest updates and service packs for Exchange Server 2003

WORKAROUND

To work around this problem, restart the appropriate service. For example, if the source of the event ID error message that is logged to the application event log is listed as MSExchangeAL, restart the System Attendant service.

STATUS

This problem was first corrected in Exchange Server 2003 Service Pack 1.

MORE INFORMATION

For additional information about the standard terminology that is used to describe Microsoft software updates, click the following article number to view the article in the Microsoft Knowledge Base:

824684 (http://support.microsoft.com/kb/824684/) Description of the standard terminology that is used to describe Microsoft software updates

For additional information about the naming schema for Exchange Server updates, click the following article number to view the article in the Microsoft Knowledge Base:

817903 (http://support.microsoft.com/kb/817903/) New naming schema for Exchange Server software update packages

Posted in IT, Exchange Server Support | No Comments »

HOW TO: Secure Communication Between a Client and Server with Terminal Services?

July 13th, 2006

View products that this article applies to.

Article ID	:	816594
Last Review	:	March 1, 2004
Revision	:	4.0

For a Microsoft Windows 2000 version of this article, see 306561 (http://support.microsoft.com/kb/306561/EN-US/).

On This Page

		IN THIS TASK
		SUMMARY
		To Secure Communications
		REFERENCES
	APPLIES TO

IN THIS TASK

•

SUMMARY

•	To Secure Communications

•

REFERENCES

SUMMARY

This step-by-step article describes how to secure communications between a client computer and a server by using Windows Server 2003 Terminal Services.

Windows Server 2003 Terminal Services supports four levels of encryption: Low, Client Compatible, FIPS Compliant, and High. The following list describes what the encryption levels do:

•	Low: This level encrypts data sent from the client to the server using 56-bit encryption, helps secure the user logon information and data that is sent to the server, but does not encrypt the data that is sent from the server to the client. Microsoft recommends that you use this encryption level in an intranet environment.
•	Client Compatible: This level encrypts data sent between the client and the server at the maximum key strength that the client supports. Use this level when the terminal server runs in an environment that contains mixed or earlier-version clients.
•	FIPS Compliant: This level encrypts and decrypts data sent from a client to the server and from the server to a client with the Federal Information Processing Standard (FIPS) encryption algorithms by using the Microsoft cryptographic modules.
•	High: By default, Windows Server 2003 uses this level of encryption. High encryption encrypts the data transmission in both directions by using a 128-bit key. Microsoft recommends that you use this encryption level if the network is not secure and is located in North America. Use this level when the terminal server runs in an environment that contains 128-bit clients only (such as Remote Desktop Connection clients). Clients that do not support this level of encryption cannot connect.

To Secure Communications

To modify the encryption setting:

1.	Click Start, point to Administrative Tools, and then click Terminal Services Configuration.
2.	In the left pane, click Connections, and then double-click the connection whose encryption level you want to change.
3.	Click General.
4.	In the Encryption level box, click the appropriate encryption level, and then click OK.

Note The new encryption level takes effect the next time a user logs on. If you require multiple levels of encryption on one server, install multiple network adapters and configure each adapter separately.

REFERENCES

For additional information about Terminal Services in Windows 2003, click the following article number to view the article in the Microsoft Knowledge Base:

814585 (http://support.microsoft.com/kb/814585/EN-US/) HOW TO: Connect Clients to Terminal Services in Windows Server 2003

814593 (http://support.microsoft.com/kb/814593/EN-US/) HOW TO: Deactivate or Reactivate a License Server By Using Terminal Services Licensing

Posted in IT | No Comments »

Terminal Server Licensing

July 13th, 2006

Terminal Server’s licensing requirements are different from those of Windows NT Server. Terminal Server Clients require two licenses to connect to a Terminal Server.

The first license is a Windows NT Workstation license. This is necessary because the Terminal Server Client effectively provides a Windows NT Workstation to the client. If the RDP client is run on a computer running Windows NT 4.0 (Server, Workstation, or Terminal Server) client already purchased the license, and it is not necessary to purchase an additional Windows NT Workstation. If the RDP client is run on a Windows NT 3.5x computer, then that client requires a Windows NT Workstation Upgrade license. If the RDP client is run on a Windows 95 or Windows for Workgroups 3.11 computer, then the client requires a Windows NT Workstation full license. These three license types are displayed in Terminal Server License Manager. In the right pane of the display, notice that the first license category of existing Windows NT Workstation licenses is ‘unlimited.’ The Full and Upgrade license types, however, will display how many licenses have been purchased and entered into Terminal Server License Manager.

The second license is a Client Access License for the server. This is the standard server access license measured in License Manager, the same utility that is in Windows NT Server. License Manager does not distinguish between RDP client access and other types of server access (for example, it does not distinguish between a normal shared file and printer resource access). Per Server and Per Seat modes are identical to those of Windows NT Server 4.0.

Terminal Server License Manager reports but does not enforce licensing. Enforcement comes from the License Manager in Windows NT. If an RDP client is denied access to the server when it tries to make a connection, increasing the license count in Terminal Server License Manager will not resolve the problem. Client Access Licenses must be added to License Manager.

If License Manager denies an RDP client access, the event will be recorded as event 201 in the Event Log. The event message will show that a license was not available for SYSTEM to access the TermService.

If Client Access Licenses are available in License Manager, and Terminal Server License Manager runs out of needed licenses, a temporary license will be granted. In this case, a fourth and fifth category of license can appear in Terminal Server License Manager: Temporary Windows NT Workstation Full license, or Temporary Windows NT Workstation Upgrade license. These licenses are good for 60 days. The RDP client making use of a temporary license will continue to do so for the full 60 days even if new licenses are added. After 60 days, the client’s temporary license will expire, and the client will get a new license (either a temporary license if no normal licenses are available, or one of the new licenses that have been added).

NOTE: Logging on at the Terminal Server console uses one Client Access License, but this is not reflected in the license count in License Manager. In the event that only one Client Access License is available, RDP clients (at the console or elsewhere) will not be able to connect even though the License Manager in-use license count is zero.

If no Client Access Licenses are available, not even the administrator can connect through the RDP client. This is different from normal licensing behavior because administrators can always log on at the console or connect to the server remotely even if no licenses are available. Administrators must log on at the Terminal Server console, or access the server by means other than the RDP client, if the Terminal Server runs out of licenses.

When an RDP client is denied access, the client will receive the generic message, ‘Terminal Server has ended the connection.’

License information is recorded on the Terminal Server, Windows NT, and Windows 95 computers under:

HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing

Licenses are stored on the Terminal Server in the %systemroot%\system32\lserver directory in the hydra.mdb file. Computers running Windows for Workgroups 3.11 store licensing information in the *.bin files in the Regdata directory under System. The typical path is C:\Windows\System\Regdata.

Terminal Server License Manager creates seven temporary files in the System32 directory. The temporary files are called JET1.TMP through JET7.TMP. These files are used to temporarily store newly created licenses.

When an RDP client connects to a Terminal Server and requests a license, the initial license is generated and cached in the appropriate JETx.TMP file. The license is sent to the client, and the client stores the license (in the registry or in the mstsc.ini file as mentioned). Licenses are tied to the client computer, so some computer-specific information is added to the license, during the license request or when the license is presented to the client (the details on this process are sketchy. Please comment this article if you have further information). The license is presented to the Terminal Server as part of logon, written to the license database, and removed from the JETx.TMP file.

It is possible to have more than seven JETx.TMP files. If the server is powered off without using the shutdown routine or if the server is shut down inside an RDP client session, the JETx.TMP files are not cleaned up. Shutting the server down through an RDP client session is generally not an issue, since services are written to handle power outages by committing cached data very quickly. Administrators should be aware, however, that the normal shutdown procedures are not followed. If you shut down the server at the console, all services are stopped before the server shuts down. The server shuts down immediately, without stopping services correctly if the shutdown is performed through a client session. Because services are not notified, the JETx.TMP files will already exist when the server is restarted. The Terminal Server License Manager service will create seven new JETx.TMP files.

If JETx.TMP files numbered 1-7 exist, the server will create new files numbered 8-14. If you deleted files 1-7 (which could be done since they would not be open) and shutdown the system through the RDP client again, the new files created at startup would again be numbered 1-7. So, the highest numbered files are not necessarily the files that are in use

If left over JETx.TMP files are an issue, simply delete JET*.TMP files. Only the closed, unused files will be deleted. You cannot delete open files, or delete files in use.

Posted in Remote Access | No Comments »

Microsoft Software Update Service (SUS)

July 13th, 2006

Purpose & Scope

What is SUS

Procedure

Microsoft SUS is a free patch management tool provided by Microsoft to help network administrators deploy security patches more easily. In simple terms, Microsoft SUS is a version of Windows Update that you can run on your network.

Today corporations have to frequently check the Windows Update site or the Microsoft Security Web site for patches. Then they have to manually download patches that have been made available since they last visited the site, test the patches, and then distribute the patches manually or by using their traditional software-distribution tools.

Instead of each workstation having to connect to the Internet to update Windows, each workstation connects to the Microsoft SUS Server instead and updates from there. Microsoft SUS Server alone requires access to the public Internet as it connects to Windows Update.

Software Update Services solves these problems by providing dynamic notification of critical updates to Windows computers as well as automatic distribution of those updates to your corporate Windows desktops and servers. For Software Update Services to function, only one corporate intranet computer requires access to the public Internet.

By connecting to Windows Update, Microsoft SUS Server provides notification of critical updates as well as performing automatic distribution of those updates to your workstations and servers. Microsoft SUS server gives the administrator control over updates: The administrator can test and approve updates from the public Windows Update site before deployment on the corporate intranet. Deployment takes place on a schedule created by the administrator.

Software Update Services leverages the successful Windows Automatic Updates service first available in Windows XP, and allows information technology professionals to configure a server that contains content from the live Windows Update site in their own Windows-based intranets to service corporate servers and clients.

Software Update Services

The server features include:

· Built-in security. The administrative pages are restricted to local administrators on the computer that hosts the updates. The synchronization validates the digital certificates on any downloads to the update server. If the certificates are not from Microsoft, the packages are deleted.

· Selective content approval. Updates synchronized to your server running Software Update Services are not made automatically available to the computers that have been configured to get updates from that server. The administrator approves the updates before they are made available for download. This allows the administrator to test the packages being deploying them.

· Content synchronization. The server is synchronized with the public Windows Update service either manually or automatically. The administrator can set a schedule or have the synchronization component of the server do it automatically at preset times. Alternatively, the administrator can use the Synchronize Now button to manually synchronize.

· Server-to-server synchronization. Because you may need multiple servers running Microsoft SUS inside your corporation in order to bring the updates closer to your desktops and servers for downloading, Microsoft SUS will allow you to point to another server running Microsoft SUS instead of Windows Update, allowing these critical software updates to be distributed around your enterprise.

· Update package hosting flexibility. Administrators have the flexibility of downloading the actual updates to their intranet, or pointing computers to a worldwide network of download servers maintained by Microsoft. Downloading updates might appeal to an administrator with a network closed to the Internet. Large networks spread over geographically disparate sites might find it more beneficial to use the Microsoft maintained download servers. These are the actual Windows Update download servers. In a scenario like this, an administrator would download and test updates at a central site, then point computers requiring updates to one of the Windows Update download servers. Microsoft maintains a worldwide network of these type servers.

· Multi-language support. Although the Software Update Services administrative interface is available only in English or Japanese, the server supports the publishing of updates to multiple operating-system language versions. Administrators can configure the list of languages for which they want updates downloaded.

· Remote administration via HTTP or HTTPS. The administrative interface is Web-based and therefore allows for remote (internal) administration using Internet Explorer 5.5 or higher.

· Update status logging. You can specify the address of a Web server where the Automatic Updates client should send statistics about updates that have been downloaded, and whether the updates have been installed. These statistics are sent using the HTTP protocol and appear in the log file of the Web server.

Download Software Update Services Server 1.0 with Service Pack 1 HERE (33mb)

Microsoft SUS Server limitations

Though very good as what it does, Microsoft’s patch management tool does have a few limitations:

· It does not push out service packs; you need a separate solution for that.

· It only handles patches at operating system level (including Internet Explorer and IIS), but not application patches such as Microsoft Office, Microsoft Exchange Server, Microsoft SQL Server, etc.

· It requires Windows 2000 and up, so it cannot patch Windows NT 4 systems.

· It cannot deploy custom patches for third party software.

· It does not allow you to scan your network for missing patches, so you cannot check if everything has been installed correctly. There is no easy reporting system for this.

This means that you still require a patch management solution to perform the above tasks. Microsoft does not plan to add the above features, since it promotes Microsoft SMS server as a tool for that. So, Microsoft SUS server is ideal for operating system patches if used in conjunction with a patch management tool.

Read more on how to overcome SUS’s limitations by using a 3rd party tool called GFI LANguard Network Security Scanner.

Windows Automatic Update Client

To use SUS on your network you will need to use the Windows Automatic Update Client.

The client is based on the Windows Automatic Updates technology that was significantly updated for Windows XP. Automatic Updates is a proactive pull service that enables users with administrative privileges to automatically download and install Windows updates such as critical operating-system fixes and Windows security patches. The features include:

Built-in security: Only users with local administrative privileges can interact with Automatic Updates. This prevents unauthorized users from tampering with the installation of critical updates. Before installing a downloaded update, Automatic Updates verifies that Microsoft has digitally signed the files.
Just-in-time validation: Automatic Updates uses the Windows Update service technologies to scan the system and determine which updates are applicable to a particular computer.
Background downloads: Automatic Updates uses the Background Intelligent Transfer Service (BITS), an innovative bandwidth-throttling technology built into Windows XP and newer operating systems, to download updates to the computer. This bandwidth-throttling technology uses only idle bandwidth so that downloads do not interfere with or slow down other network activity, such as Internet browsing.
Chained installation: Automatic Updates uses the Windows Update technologies to install downloaded updates. If multiple updates are being installed and one of them requires a restart, Automatic Updates installs them all together and then requests a single restart.
Multi-user awareness: Automatic Updates is multi-user aware, which means that it displays different UI depending on which administrative user is logged on.
Manageability: In an Active Directory environment, an administrator can configure the behavior of Automatic Updates using Group Policy. Otherwise, an administrator can remotely configure Automatic Updates using registry keys through the use of a logon script or similar mechanism.
Multi-language support: The client is supported on localized versions of Windows.

This update applies to the following operating systems:

Windows 2000 Professional with Service Pack 2
Windows 2000 Server with Service Pack 2
Windows 2000 Advanced Server with Service Pack 2
Windows XP Professional
Windows XP Home Edition

Note: Windows 2000 Service Pack 3 (SP3) and Windows XP Service Pack 1 (SP1) include the Automatic Updates component, eliminating the need to download the client component separately.

Download Windows automatic updating (SUS Client) HERE (1mb)

Administrator Control via Policies

The Automatic Updates behavior can be driven by configuring Group Policy settings in an Active Directory environment.

Administrators can use Group Policy in an Active Directory environment or can configure registry keys to specify a server running Software Update Services. Computers running Automatic Updates then use this specified server to get updates.

The Software Update Services installation package includes a policy template file, WUAU.ADM, which contains the Group Policy settings described earlier in this paper. These settings can be loaded into Group Policy Editor for deployment. These policies are also included in the System.adm file in Windows 2000 Service Pack 3, and will be included in the Windows Server 2003 family, and in Windows XP Service Pack 1.

Download Software Update Services 1.0 ADM File for Service Pack 1 HERE (25kb)

Loading of the WUAU.ADM template in GPO

Image of the WUAU.ADM template in place

Images of the GPO setting options for Windows Automatic Updates.

After you have configured the Microsoft SUS client, patches are deployed automatically. The user is notified through a message in the task bar (see image).

System Requirements and supported clients

System Requirements:

· Supported Operating Systems: Windows 2000, Windows Server 2003

SUS Server 1.0 with SP1 has the following minimum hardware requirements:

· Pentium III 700 MHz or higher processor

· 512 megabytes (MB) of RAM

· 6 gigabytes (GB) of available hard disk space

Your client computers must be running Windows 2000 Professional with Service Pack 2 (SP2) or later, Windows XP Professional, or Windows 2000 Server with SP2 or later in order to run Automatic Updates. Note: Windows NT 4.0 is not supported.

SUS supports updates for Windows 2000 Professional with Service Pack 2, Windows 2000 Server, and Windows XP Professional. It does not include provisions for updates to any other Microsoft products such as Microsoft Office, SQL Server, or Exchange Server.

SUS with SP1 can now be used to deploy Service Packs - SP1 for XP and SP4 for W2K.

SUS Server 1.0 with SP1 automatically installs under the Web site that is currently running. It will not interfere with this or any other Web sites. If no other Web site is currently running, SUS Server 1.0 with SP1 will create a new Web site.

Here are a few screenshots of SUS and it’s main screens:

SUS Welcome screen

SUS Synchronize Now and Schedule buttons

The Synchronization settings window

The Synchronization process and detail window

The Synchronization Log

Microsoft Software Update Services (SUS)

Download Software Update Services Server 1.0 with Service Pack 1 HERE (33mb)

Download Windows automatic updating (SUS Client) HERE (1mb)

Download Software Update Services 1.0 ADM File for Service Pack 1 HERE (25kb)

Software Update Services Deployment White Paper (Doc, 2.51mb)

Posted in IT | No Comments »

I’m about to install SBS 2000 on my network. Are there any special issues to take into consideration before I start the installation?

July 13th, 2006

Question

Instructions:State the question.

Answer

SBS 2000 is an easy installation. The installation phase can be divided into 2 distinctive sections: The simple-good-old Windows 2000 setup process, and the SBS Back-office components installation phase.

Installing the W2K phase is just like installing W2K. However, after running that part there are a few things you should be aware of BEFORE you begin the second phase.

Make sure to get hold of and install SBS Service Pack 1. That is basically Windows 2000 SP3, Exchange 2000 SP3 and ISA SP1. There are other parts to the actual Service Pack but if you cannot get it on time, the regular Service Packs will be fine. Read this for more: Small Business Server 2000 Patches.

Make sure to use the wizards! When setting up users, you will use a wizard. These are very good, but you must use them so you do not get into issues with security. Specifically, the wizard creates a client setup disk for use on each PC. During the installation (on the client) the setup disk sets up the local user rights etc.

Set up all users with Power User rights (done using the wizard). This will allow them to add software etc. However, you do not need to do this. Just a suggestion.

Unlike the previous versions of SBS, you can set the IP addressing as you wish without issue.

During the installation, make sure to set the Company Shared Folder and Users Shared Folder onto a drive with enough storage space for the future. These folders are automatically referenced on each users desktop after installation, so SBS wants the users to use them.

SBS will automatically set the users personal folder to map to the ‘Z’ drive. No need for you do do manually. However, if you do not want passwords to expire, you will need to make this change using AD Users and Groups.

Also, SBS 2000 does not by default set-up profile paths if you want to use them you’ll have to do it manually.

If you have more than one network card make sure to disable the one that will NOT be used for the internal network. SBS hates that. If you are going to set-up a broadband or router on the other network card, only enable it after the installation of the main system.

After the initial installation, you will be presented with a ‘To do’ list. It is VITAL that you set the ‘Configure Internet Information Services’. If you do not do this, everything fails after a while.

Make sure to use the ‘Internet Connection Wizard’ under the ‘to do’ list to configure your internet settings. This will set-up IIS, ISA, Exchange and Internet settings for you. It is very good, but you can make your own changes the good old manual way after. Remember, if you make your own changes, they would be reset by the wizard if you ran it again.

Oh, one last thing…. You HAVE to use NTFS format.

Posted in IT | 1 Comment »

How to enable/configure Terminal Services Encryption?

July 13th, 2006

Question

Instructions:State the question.

Answer

Windows Server 2003 Terminal Services supports four levels of encryption: Low, Client Compatible, FIPS Compliant, and High.

The following list describes what the encryption levels do: • Low: This level encrypts data sent from the client to the server using 56-bit encryption, helps secure the user logon information and data that is sent to the server, but does not encrypt the data that is sent from the server to the client. Microsoft recommends that you use this encryption level in an intranet environment.

• Client Compatible: This level encrypts data sent between the client and the server at the maximum key strength that the client supports. Use this level when the terminal server runs in an environment that contains mixed or earlier-version clients.

• FIPS Compliant: This level encrypts and decrypts data sent from a client to the server and from the server to a client with the Federal Information Processing Standard (FIPS) encryption algorithms by using the Microsoft cryptographic modules.

• High: By default, Windows Server 2003 uses this level of encryption. High encryption encrypts the data transmission in both directions by using a 128-bit key. Microsoft recommends that you use this encryption level if the network is not secure and is located in North America. Use this level when the terminal server runs in an environment that contains 128-bit clients only (such as Remote Desktop Connection clients). Clients that do not support this level of encryption cannot connect.

To Secure Communications:

To modify the encryption setting:

1. Click Start, point to Administrative Tools, and then click Terminal Services Configuration.

2. In the left pane, click Connections, and then double-click the connection whose encryption level you want to change.

3. Click General.

4. In the Encryption level box, click the appropriate encryption level, and then click OK.

Note The new encryption level takes effect the next time a user logs on. If you require multiple levels of encryption on one server, install multiple network adapters and configure each adapter separately.

Posted in IT | No Comments »

How do I use Group Policy to deploy Windows XP in a Windows 2000 network?

July 13th, 2006

Question
Instructions:State the question.

Answer
1. the appropriate permissions to allow the users and the computers to read and run the files, and then copy the I386 folder from the Windows XP Professional CD-ROM to this folder.

2. You can create a GPO for a domain, an organizational unit, or a site. It is recommended that you assign a GPO to an organizational unit that contains the users whose workstations you want to upgrade.

3. In that GPO, click to expand User Configuration, and then click to expand Software Settings.

4. Right-click Software installation, point to New, and then click Package.

5. In the Look in box, browse to the share where the I386 folder is located.

6. Make sure that the path that you enter is an accessible Universal Naming Convention (UNC) path and not a file system path.

7. Open the share that contains the Windows Installer package, click Winnt32.msi, and then click Open.

8. Click Publish, and then click OK.

Note: When you make changes to the GPO, these changes are not applied immediately to the target computers. Instead, they are applied according to the currently valid Group Policy refresh interval. In this scenario, when the program has been published to the users, it is available the next time the affected users log on.

Posted in Uncategorized | No Comments »

How do I install Active Directory on my Windows Server 2003 server?

July 13th, 2006

Question

Instructions:State the question.

Answer

First make sure you read and understand Active Directory Installation Requirements. If you don’t comply with all the requirements of that article you will not be able to set up your AD (for example: you don’t have a NIC or you’re using a computer that’s not connected to a LAN).

Note: This article is only good for understanding how to install the FIRST DC in a NEW AD Domain, in a NEW TREE, in a NEW FOREST. Meaning - don’t do it for any other scenario, such as a new replica DC in an existing domain. In order to install a Windows Server 2003 DC in an EXISTING Windows 2000 Domain follow the Windows 2003 ADPrep tip.

Daniel’s recommendations

Daniel Petri

Windows 2000 Note: If you plan to install a new Windows 2000 DC please read How to Install Active Directory on Windows 2000.

Windows Server 2003 Note: If you plan to install a new Windows Server 2003 DC in an existing AD forest please read the page BEFORE you go on, otherwise you’ll end up with the following error:

Here is a quick list of what you must have:

· An NTFS partition with enough free space

· An Administrator’s username and password

· The correct operating system version

· A NIC

· Properly configured TCP/IP (IP address, subnet mask and - optional - default gateway)

· A network connection (to a hub or to another computer via a crossover cable)

· An operational DNS server (which can be installed on the DC itself)

· A Domain name that you want to use

· The Windows Server 2003 CD media (or at least the i386 folder)

· Brains (recommended, not required…)

This article assumes that all of the above requirements are fulfilled.

Step 1: Configure the computer’s suffix

(Not mandatory, can be done via the Dcpromo process).

1. Right click My Computer and choose Properties.

2. Click the Computer Name tab, then Change.

3. Set the computer’s NetBIOS name. In Windows Server 2003, this CAN be changed after the computer has been promoted to Domain Controller.

4. Click More.

5. In the Primary DNS suffix of this computer box enter the would-be domain name. Make sure you got it right. No spelling mistakes, no ‘oh, I though I did it right…’. Although the domain name CAN be changed after the computer has been promoted to Domain Controller, this is not a procedure that one should consider lightly, especially because on the possible consequences. Read more about it on my Windows 2003 Domain Rename Tool page.

6. Click Ok.

7. You’ll get a warning window.

8. Click Ok.

9. Check your settings. See if they’re correct.

10. Click Ok.

11. You’ll get a warning window.

12. Click Ok to restart.

Step 2: Configuring the computer’s TCP/IP settings

You must configure the would-be Domain Controller to use it’s own IP address as the address of the DNS server, so it will point to itself when registering SRV records and when querying the DNS database.

Configure TCP/IP

1. Click Start, point to Settings and then click Control Panel.

2. Double-click Network and Dial-up Connections.

3. Right-click Local Area Connection, and then click Properties.

4. Click Internet Protocol (TCP/IP), and then click Properties.

5. Assign this server a static IP address, subnet mask, and gateway address. Enter the server’s IP address in the Preferred DNS server box.

Note: This is true if the server itself will also be it’s own DNS server.

If you have another operational Windows 2000/2003 server that is properly configured as your DNS server (read my Create a New DNS Server for AD page) - enter that server’s IP address instead:

6. Click Advanced.

7. Click the DNS Tab.

8. Select ‘Append primary and connection specific DNS suffixes’

9. Check ‘Append parent suffixes of the primary DNS suffix’

10. Check ‘Register this connection’s addresses in DNS’. If this Windows 2000/2003-based DNS server is on an intranet, it should only point to its own IP address for DNS; do not enter IP addresses for other DNS servers here. If this server needs to resolve names on the Internet, it should have a forwarder configured.

11. Click OK to close the Advanced TCP/IP Settings properties.

12. Click OK to accept the changes to your TCP/IP configuration.

13. Click OK to close the Local Area Connections properties.

Step 3: Configure the DNS Zone

(Not mandatory, can be done via the Dcpromo process).

This article assumes that you already have the DNS service installed. If this is not the case, please read Create a New DNS Server for AD.

Furthermore, it is assumed that the DC will also be it’s own DNS server. If that is not the case, you MUST configure another Windows 2000/2003 server as the DNS server, and if you try to run DCPROMO without doing so, you’ll end up with errors and the process will fail.

Creating a Standard Primary Forward Lookup Zone

1. Click Start, point to All Programs, point to Administrative Tools, and then click DNS Manager. You see two zones under your computer name: Forward Lookup Zone and Reverse Lookup Zone.

2. Right click Forward Lookup Zones and choose to add a new zone.

3. Click Next. The new forward lookup zone must be a primary zone so that it can accept dynamic updates. Click Primary, and then click Next.

4. The name of the zone must be the same as the name of the Active Directory domain, or be a logical DNS container for that name. For example, if the Active Directory domain is named ‘lab.dpetri.net’, legal zone names are ‘lab.dpetri.net’, ‘dpetri.net’, or ‘net’.

Type the name of the zone, and then click Next.

Accept the default name for the new zone file. Click Next.

6. To be able to accept dynamic updates to this new zone, click ‘Allow both nonsecure and secure dynamic updates’. Click Next.

7. Click Finish.

You should now make sure your computer can register itself in the new zone. Go to the Command Prompt (CMD) and run ‘ipconfig /registerdns‘ (no quotes, duh…). Go back to the DNS console, open the new zone and refresh it (F5). Notice that the computer should by now be listed as an A Record in the right pane.