Logo ADS-Training Home   All Libraries and Lists   Site Management   Create (reserved)   Site Help   
Icon
ADS-Training InfoCenter
Windows White Papers and Library
 
 
 
Select a View
All Items
Show comments and details
Complete list
 
 
Actions
  Alert me
  Export to spreadsheet
  Modify settings and columns
 
 
New New Item
|
Filter Filter
|
Edit in Datasheet Edit in Datasheet
 
TitleBodyFilterCategoriesOS concernedTechnologies
Systems Center Operations Manager 2007 Documentation
Brief Description
This download contains documentation for System Center Operations Manager 2007.
Overview
This download contains the following documentation for System Center Operations Manager 2007:
• Operations Manager 2007 Deployment Guide:
This guide steps you through the deployment process for System Center Operations Manager 2007.
• Active Directory Management Pack Guide for Operations Manager 2007:
This document includes a Management Pack overview, deployment procedures, and monitoring scenarios for the two Active Directory Domain Services (AD DS) Management Packs
• Exchange Management Pack Guide for Operations Manager 2007: This guide includes a Management Pack overview, deployment procedures, and monitoring scenarios for the Microsoft Exchange Server 2003 Management Pack for Microsoft System Center Operations Manager 2007.
• SQL Management Pack Guide for Operations Manager 2007:
The SQL Server Management Pack provides both proactive and reactive monitoring of SQL Server 2000 and SQL Server 2005 for an enterprise environment.
• Windows Server Operating System Management Pack Guide for Operations Manager 2007:
The Microsoft Windows Server Management Packs monitor the performance, health, and availability of Microsoft Windows 2000 Server and Microsoft Windows Server 2003.
• Windows Client Operating System Management Pack Guide:
The Windows client operating system Management Packs are intended for use in gathering data on client computers or individually monitoring designated mission-critical client computers.
• Operations Manager 2007 Terminal Services Management Pack: This guide includes an overview of the Management Pack, deployment procedures, and monitoring scenarios for the Terminal Services Management Pack.
• Operations Manager 2007 Security Guide:
This guide provides you with security-related information as it pertains to Operations Manager 2007.
• Operations Manager 2007 Management Pack Guide:
This guide includes a Management Pack overview, deployment procedures, and monitoring scenarios for the Microsoft Windows Server Internet Information Services 2000 and 2003 Management Packs for Microsoft System Center Operations Manager 2007.
• Operations Manager 2007 Management Pack Terminal Services:
This guide includes an overview of the Management Pack, deployment procedures, and monitoring scenarios for the Terminal Services Management Pack.
• The Operations Manager 2007 Design Guide:
This guide steps the reader through the steps necessary to develop a complete architectural plan for their OpsMgr2007 implementation.
• Operations Manager 2007 Backup and Recovery Guide:
This guide provides guidance in planning for backup and recovery of System Center Operations Manager 2007 server roles and components. The information in this guide will complement your existing recovery strategy to avoid service disruption.
 
To download, click this link:
ArchitectWindows Server 2003Active Directory
Wireless LAN Technologies and Microsoft Windows
Attachment
This article describes the benefits of wireless LANs, the support for 802.11 wireless LAN and wireless LAN security standards in Microsoft® Windows®, and general guidelines for wireless LANs in medium to large organizations and small office/home office networks.
 
On This Link, you can find:
 
  •  Benefits of Wireless LANs 
  •  Support for IEEE 802.11 Standards 
  •  Support for IEEE 802.11 Security Standards 
  •  Checklists and Resources
Architect; Deploy; Security ServicesWindows Server 2003; WIndows XP ProfessionalActive Directory
Understanding Digital Certificates and Public Key Cryptography
Attachment
Although public key cryptography simplifies key management by allowing one key pair to be used by many people, there is a problem: how to distribute a public key so that the user can find it and know that it is valid.
 
To read all, click this cool document!
 
Architect; Security ServicesWindows Server 2003Active Directory
Introduction to Network Access Protection
Attachment
Network Access Protection (NAP) is a new platform to perform computer health policy validation, ensure ongoing compliance with health policies, and optionally restrict the access of computers that do not comply with system health requirements until their health state can be corrected.
 
Network Access Protection includes a client and server architecture. Administrators can configure Internet Protocol security (IPsec) Enforcement, IEEE 802.1X Enforcement, virtual private network (VPN) Enforcement, Dynamic Host Configuration Protocol (DHCP) Enforcement, or all four, depending on their network needs.
 
Network Access Protection provides an infrastructure and an API set for extending Network Access Protection functionality. Vendors and software developers can use the API set to build their own network policy validation, ongoing network policy compliance, and network isolation components that are compatible with Network Access Protection.
 
For a Webcast version of this white paper, click here:
 
 
Note The Network Access Protection platform is not the same as Network Access Quarantine Control, which is a capability provided with Windows Server 2003 to provide additional protection for remote access (dial-up and virtual private network [VPN]) connections. For more information, see Network Access Quarantine Control in Windows Server 2003.
 
For More Information:

 

ArchitectWindows Server 2003Active Directory; DHCP; DNS
Windows Server 2003 and WMS at ETSI by JF Aprea and JL Freisse
Attachment
European Telecommunications Standards Institute (ETSI) doubled the frame rate display – from 15 frames per second to 30 frames per second – by upgrading to the Microsoft Windows Server 2003 Enterprise Edition operating system and Windows Media Services 9 Series. The doubling of frame rates – which provides an appreciable benefit for viewers – was seen on the same hardware that had previously been running the Windows 2000 Server operating system and Windows Media Services 8.0. ETSI also gained tighter security measurements and easier system administration with its upgrade to Windows Server 2003.
Case StudyWindows Server 2003Active Directory; MSCS
How Volume Shadow Copy Service Works
Attachment
The Volume Shadow Copy Service provides the backup infrastructure for the Microsoft Windows XP and Microsoft Windows Server 2003 operating systems, as well as a mechanism for creating consistent point-in-time copies of data known as shadow copies.
 
 
The Volume Shadow Copy Service can produce consistent shadow copies by coordinating with business applications, file-system services, backup applications, fast-recovery solutions, and storage hardware. Several features in the Windows Server 2003 operating systems use the Volume Shadow Copy Service, including Shadow Copies for Shared Folders and Backup.
 
To read all, click this link:
 
 
or the attached file !
 
 
ArchitectWindows Server 2003Active Directory
What's New in Windows Server 2003 R2
Attachment
Doing more with less just got better! Windows Server 2003 R2 simplifies branch server management, improves identity and access management, reduces storage management costs, provides a rich Web platform, and offers cost-effective server virtualization.
 
Built on Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 R2 takes advantage of the stability and security of a proven code base, while introducing new features and scenarios. In these webcasts for IT professionals, Microsoft subject matter experts walk through the new R2 enhancements and best practices for how to plan and deploy Windows Server 2003 R2.
 
ArchitectWindows Server 2003Active Directory
Virtual Server Host Clustering Step-by-Step Guide for Virtual Server 2005 R2
Attachment
This document provides an introduction to the methods and concepts of Virtual Server host clustering. With Virtual Server host clustering, you can provide a wide variety of services through a small number of physical servers and, at the same time, maintain availability of the services you provide. If one server requires scheduled or unscheduled downtime, another server is ready to quickly begin supporting services. Users experience minimal disruptions in service.
Virtual Server host clustering is a way of combining Microsoft® Virtual Server 2005 R2 with the server cluster feature in Microsoft Windows Server™ 2003. This document describes a simple configuration in which you use Microsoft Virtual Server 2005 R2 to configure one guest operating system, and configure a server cluster that has two servers (nodes), either of which can support the guest if the other server is down. You can create this configuration and then, by carefully following the pattern of the configuration, develop a host cluster with additional guests or additional nodes.
 
ArchitectWindows Server 2003Active Directory; MSCS
Session Directory and Load Balancing Using Terminal Server
Attachment
Terminal Server Session Directory is a feature that allows users to easily and automatically reconnect to a disconnected session in a load balanced Terminal Server farm.
 
The session directory keeps a list of sessions indexed by user name and server name. This enables a user, after disconnecting a session, to reconnect to the correct terminal server where the disconnected session resides to resume working in that session.
 
This reconnection will work even if the user connects from a different client computer.
This white paper discusses how to plan and deploy a load balanced terminal server farm using session directory, and how the session directory operates in a load balanced environment.
 
Included in This Document
 
• Session Directory Overview
 
• Load Balanced Configurations
 
• Session Directory
 
• Summary
 
• Appendix
 

 
Architect; Plan; Deploy; SupportWindows Server 2003Active Directory; MSCS
Best Practices: Naming conventions in Active Directory for computers, domains, sites, and OUs
Naming conventions in Active Directory for computers, domains, sites, and OUs

View products that this article applies to.
Article ID : 909264
Last Review : January 18, 2006
Revision : 1.0 
 INTRODUCTION
   Computer names
     NetBIOS computer names
     DNS computer names
   Domain names
     NetBIOS domain names
     DNS domain names
     Other factors
   Site names
   OU names 
  
 
INTRODUCTION
This article describes the naming conventions for computer accounts in Microsoft Windows, NetBIOS domain names, DNS domain names, Active Directory sites, and organizational units (OUs) that are defined in the Active Directory directory service. The topics that are discussed include the valid characters for names, the minimum and maximum name lengths, reserved names, names that we do not recommend, and general recommendations that are based on supporting Active Directory in small, medium, and large deployments.
Computer names
NetBIOS computer names
Allowed characters
NetBIOS computer names can contain all alphanumeric characters except for the extended characters that are listed in the "Disallowed characters" section. Names can contain a period, but names cannot start with a period.
Disallowed characters
NetBIOS computer names cannot contain the following characters:• backslash (\)
• slash mark (/)
• colon (:)
• asterisk (*)
• question mark (?)
• quotation mark (")
• less than sign (<)
• greater than sign (>)
• vertical bar (|)

 
Names can contain a period (.). However, the name cannot start with a period. The use of non-DNS names with periods is allowed in Microsoft Windows NT. However, periods should not be used in Microsoft Windows 2000 or in later versions of Windows. If you are upgrading a computer whose NetBIOS name contains a period, change the machine name. For more information, see the "Special characters" section.
In Windows 2000 and in later versions of Windows, computers that are members of an Active Directory domain cannot have names that are composed completely of numbers. This restriction is because of DNS restrictions. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
244412 (http://support.microsoft.com/kb/244412/) Windows 2000 does not permit all-numeric computer names
Minimum name length
1 character.
Maximum name length
15 characters.
 
Note The 16th character is reserved to identify the functionality that is installed on the registered network device.
Reserved names
See "Table of reserved words."
Special characters
Period (.).
A period character separates the name into a NetBIOS scope identifier and the computer name. The NetBIOS scope identifier is an optional string of characters that identify logical NetBIOS networks that run on the same physical TCP/IP network. For NetBIOS to work between computers, the computers must have the same NetBIOS scope identifier and unique computer names.
 
Warning The use of NetBIOS scopes in names is a legacy configuration and should not be used with Active Directory forests. For more information about NetBIOS scopes, visit the following non-Microsoft Web sites:
http://www.ietf.org/rfc/rfc1001.txt (http://www.ietf.org/rfc/rfc1001.txt)
http://www.ietf.org/rfc/rfc1002.txt (http://www.ietf.org/rfc/rfc1002.txt)
DNS computer names
Allowed characters
DNS computer names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and the period (.). Period characters are allowed only when they are used to delimit the components of domain style names.
In the Windows 2000 domain name system (DNS) and in the Microsoft Windows Server 2003 DNS, the use of Unicode characters is supported. Other implementations of DNS do not support Unicode characters. Avoid Unicode characters if queries will be passed to the servers that use non-Microsoft implementations of DNS.
Disallowed characters
DNS host names cannot contain the following characters:• comma (,)
• tilde (~)
• colon (:)
• exclamation point (!)
• at sign (@)
• number sign (#)
• dollar sign ($)
• percent (%)
• caret (^)
• ampersand (&)
• apostrophe (')
• period (.)
• parentheses (())
• braces ({})
• underscore (_)

In DNS, a period breaks the name into a different namespace. In this scenario, such use is not valid.
The DNS host name cannot contain blank or space characters.
No distinction is made between upper and lowercase.
The first character must be alphabetical or numeric.
The last character must not be a minus sign or a period.
In Windows 2000 and in later versions of Windows, computers that are members of an Active Directory domain cannot have names that are composed completely of numbers. This restriction is because of DNS restrictions. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

244412 (http://support.microsoft.com/kb/244412/) Windows 2000 does not permit all-numeric computer names
Minimum name length
2 characters.
Maximum name length
24 characters.
The maximum length of the host name and of the fully qualified domain name (FQDN) is 63 octets per label and 255 bytes per FQDN. This maximum includes 254 bytes for the FQDN and one byte for the ending dot.
 
In Windows 2000 and in Windows Server 2003, the maximum host name and the FQDN use the standard length limitations that are mentioned earlier, with the addition of UTF-8 (Unicode) support. Because some UTF-8 characters exceed one octet in length, you cannot determine the size by counting the characters.
 
Domain controllers must have an FQDN of less than 155 bytes.
Reserved names per RFC
• -GATEWAY
• -GW
• -TAC
• Top-level Internet domain names, such as com, .net, .org, .us, .fr, and .gr
 
Reserved names in Windows
See "Table of reserved words."
Best practices
When you create names for the DNS computers in a new Windows Server 2003 DNS infrastructure, use the following guidelines: • Choose computer names that are easy for users to remember.
• Identify the owner of the computer in the computer name. 
• Choose a name that describes the purpose of the computer. 
• Do not use character case to indicate the owner or the purpose of a computer. DNS is not case-sensitive.
• Match the Active Directory domain name to the primary DNS suffix of the computer name.
• Use a unique name for every computer in your organization. Do not assign the same computer name to computers in different DNS domains.
• Use ASCII characters. This guarantees interoperability with computers that are running versions of Windows that are earlier than Windows 2000.
• In DNS computer names, use only the characters that are listed in RFC 1123. These characters include A–Z, a–z, 0–9, and the hyphen (-). In Windows Server 2003, DNS allows most UTF-8 characters in names. However, do not use extended ASCII or UTF-8 characters unless all the DNS servers in your environment support them.
 
 
Domain names
NetBIOS domain names
Allowed characters
NetBIOS domain names can contain all alphanumeric characters except for the extended characters that are listed in the "Disallowed characters" section. Names can contain a period, but names cannot start with a period.
Disallowed characters
NetBIOS computer names cannot contain the following characters:• backslash (\)
• slash mark (/)
• colon (:)
• asterisk (*)
• question mark (?)
• quotation mark (")
• less than sign (<)
• greater than sign (>)
• vertical bar (|)
Names can contain a period (.). However, the name cannot start with a period. The use of non-DNS names with periods is allowed in Microsoft Windows NT. However, periods should not be used in Active Directory domains. If you are upgrading a domain whose NetBIOS name contains a period, change the name by migrating the domain to a new domain structure. Do not use periods in new NetBIOS domain names.
 
In Windows 2000 and in later versions of Windows, computers that are members of an Active Directory domain cannot have names that are composed completely of numbers. This restriction is because of DNS restrictions.
Minimum name length
1 character.
Maximum name length
15 characters.
 
Note The 16th character is reserved to identify the functionality that is installed on the registered network device.
Reserved names in Windows
See "Table of reserved words."
 
The names of an upgraded domain can include a reserved word. However, trust relationships with other domains fail when this is true. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
836182 (http://support.microsoft.com/kb/836182/) You cannot establish a trust relationship to another Windows 2000 domain
Special characters
Period (.).
A period character separates the name into a NetBIOS scope identifier and the computer name. The NetBIOS scope identifier is an optional string of characters that identify logical NetBIOS networks that run on the same physical TCP/IP network. For NetBIOS to work between computers, the computers must have the same NetBIOS scope identifier and unique computer names.
 
Warning The use of NetBIOS scopes in names is a legacy configuration and should not be used with Active Directory forests.

DNS domain names

Allowed characters
DNS host names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and the period (.). Period characters are allowed only when they are used to delimit the components of domain style names.
In the Windows 2000 domain name system (DNS) and in the Microsoft Windows Server 2003 DNS, the use of Unicode characters is supported. Other implementations of DNS do not support Unicode characters. Avoid Unicode characters if queries will be passed to the servers that use non-Microsoft implementations of DNS.
 
Disallowed characters
DNS host names cannot contain the following characters:• comma (,)
• tilde (~)
• colon (:)
• exclamation point (!)
• at sign (@)
• number sign (#)
• dollar sign ($)
• percent (%)
• caret (^)
• ampersand (&)
• apostrophe (')
• period (.)
• parentheses (())
• braces ({})
• underscore (_)

In DNS, a period breaks the name into a different namespace. In this scenario, such use is not valid.
The DNS host name cannot contain blank or space characters.
No distinction is made between upper and lowercase.
The first character must be alphabetical or numeric.
The last character must not be a minus sign or a period.
Minimum name length
2 characters.
Maximum name length
24 characters.
The maximum length of the host name and of the fully qualified domain name (FQDN) is 63 octets per label and 255 bytes per FQDN. This maximum includes 254 bytes for the FQDN and one byte for the ending dot.
 
In Windows 2000 and in Windows Server 2003, the maximum host name and the FQDN use the standard length limitations that are mentioned earlier, with the addition of UTF-8 (Unicode) support. Because some UTF-8 characters exceed one octet in length, you cannot determine the size by counting the characters. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
245809 (http://support.microsoft.com/kb/245809/) Windows 2000 supports fully qualified domain names up to 64 UTF-8 bytes long

Single-label domain namespaces

Single-label DNS names are names that do not contain a suffix such as .com, .corp, .net, .org or companyname. For example, "host" is a single-label DNS name. Most Internet registrars do not allow the registration of single-label DNS names.
Generally, we recommend that you register DNS names for internal and external namespaces with an Internet registrar. This includes the DNS names of Active Directory domains, unless such names are subdomains of DNS names that are registered by your organization name. For example, "corp.example.com" is a subdomain of "example.com." Registering your DNS name with an Internet registrar may help prevent a name collision. A name collision may occur if another organization tries to register the same DNS name or if your organization merges with another organization that uses the same DNS name.
 
Problems that are associated with single-label namespaces include the following: • Single-label DNS names cannot be registered by using an Internet registrar.
• Domains that have single-label DNS names require additional configuration.
• The DNS Server service may not be used to locate domain controllers in domains that have single-label DNS names.
• By default, Windows Server 2003-based domain members, Windows XP-based domain members, and Windows 2000-based domain members do not perform dynamic updates to single-label DNS zones.

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
285983 (http://support.microsoft.com/kb/285983/) Considerations for designing namespaces in a Windows 2000-based domain
300684 (http://support.microsoft.com/kb/300684/) Information about configuring Windows for domains with single-label DNS
Disjointed namespaces

Definition of a disjointed namespace
A disjointed namespace occurs when a computer's primary DNS suffix does not match the DNS domain of which it is a member. For example, a disjointed namespace occurs when a machine that has the DNS name of dc1.contosocorp.com is in a domain that has the DNS name of contoso.com.
 
How disjointed namespaces occur1. A Windows NT 4.0 primary domain controller is upgraded to a Windows 2000 domain controller by using the original release version of Windows 2000. In the Networking item in Control Panel, multiple DNS suffixes are defined.
2. The domain is renamed when the forest is at the Windows Server 2003 forest functional level, and the primary DNS suffix is not changed to reflect the new DNS domain name.
Effects of a disjointed namespace
Suppose a domain controller named DC1 resides in a Windows NT 4.0 domain whose NetBIOS domain name is contoso. This domain controller is upgraded to Windows 2000. When this upgrade occurs, the DNS domain is renamed contoso.com. In the original release version of Windows 2000, the upgrade routine clears the check box that links the primary DNS suffix of the domain controller to its DNS domain name. Therefore, the primary DNS suffix of the domain controller is the DNS suffix that was defined in the Windows NT 4.0 suffix search list. In this example, the DNS name is DC1.northamerica.contoso.com.
The domain controller dynamically registers its service location (SRV) records in the DNS zone that corresponds to its DNS domain name. However, the domain controller registers its host records in the DNS zone that corresponds to its primary DNS suffix.
 
Note Host records are also known as "A records" or "glue records."
When you intentionally create a disjointed namespace, configure forwarders or delegations in the DNS zones. Configure these forwarders or delegations between both forward lookup zones so that the host records can be located. For example, configure forwarders between the contoso.com and northamerica.contoso.com. If a disjointed namespace is created unintentionally, if no forwarders are configured, and if the DNS zones are created by the Active Directory Installation Wizard, no zone is created for the primary DNS suffix zone. When this configuration requirement is not satisfied, clients cannot resolve DNS requests for services to the IP addresses of the domain controllers that provide these services. In this scenario, AD replication and other operations experience a DNS lookup error. These operations fail because the SRV record request points to a host record that does not exist in the zone. Or, these operations fail because the host record is in a zone that cannot be reached through a forwarder.
 
Preventing disjointed namespace problems

When a Windows NT 4.0 primary domain controller is upgraded to the original release version of Windows 2000, the Change primary DNS suffix when domain membership changes check box is unchecked. This problem was corrected in Windows 2000 Service Pack 1. To work around this problem, use one of the following methods: • Select the Change primary DNS suffix when domain membership changes check box.
• Perform a slipstream of the service pack with the installation media so that the upgrade automatically upgrades the domain controller to the current service pack.
After you perform a domain rename, make sure that you modify the DNS suffix of the domain controllers so that it matches the new domain namespace.
Best practices

• Before you upgrade a Windows NT 4.0 domain controller, modify the DNS suffix of the computer in the TCP/IP Properties dialog box to match the DNS suffix of the Windows 2000 domain of which it will be a member.
• Before you run the Active Directory Installation Wizard on a Windows 2000 member server, make sure that the Change primary DNS suffix when domain membership changes check box is selected. To locate this check box, follow these steps: 1. Right-click My Computer, and then click Properties.
2. In the System Properties dialog box, click the Network Identification tab, and then click Properties.
3. In the Identification Changes dialog box, click More.
By default, the Change primary DNS suffix when domain membership changes check box is selected on a Windows 2000-based computer, unless it has been upgraded from Windows NT 4.0.
• Before you upgrade the first domain controller, plan the DNS namespace. Otherwise, you may incorrectly answer namespace questions in the Active Directory Installation Wizard.

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
285983 (http://support.microsoft.com/kb/285983/) Considerations for designing namespaces in a Windows 2000-based domain
262376 (http://support.microsoft.com/kb/262376/) Computer name does not match the Windows 2000 domain name after upgrade
257623 (http://support.microsoft.com/kb/257623/) The DNS suffix of the computer name of a new domain controller may not match the name of the domain after you upgrade a Windows NT 4.0 primary domain controller to Windows 2000
292541 (http://support.microsoft.com/kb/292541/) How to rename the DNS name of a Windows 2000 domain
296592 (http://support.microsoft.com/kb/296592/) How to rename a Windows 2000 domain controller
Reserved names
See "Table of reserved words."
 
Do not use top-level Internet domain names on the intranet. Top-level Internet domain names include .com, .net, .org, .us, .fr, and .gr. If you use top-level Internet domain names on the intranet, computers on the intranet that are also connected to the Internet may experience resolution errors.
Other factors

Forests that are connected to the Internet
A DNS namespace that is connected to the Internet must be a subdomain of a top-level or second-level domain of the Internet DNS namespace.

Maximum number of domains in a forest
In Windows 2000, the maximum number of domains in a forest is 800.
In Windows Server 2003, the maximum number of domains at Forest Functional Level 2 is 1200. This restriction is a limitation of multivalued non-linked attributes in Windows Server 2003.
Best practices

• Because the DNS names of all the nodes that require name resolution include the Internet DNS domain name for the organization, choose an Internet DNS domain name that is short and easy to remember. Because DNS is hierarchical, DNS domain names grow when you add subdomains to your organization. Short domain names make the computer names easy to remember.

• If the organization has an Internet presence, use names that are relative to the registered Internet DNS domain name. For example, if you have registered the Internet DNS domain name contoso.com, use a DNS domain name such as corp.contoso.com for the intranet domain name.
• Do not use the name of an existing corporation or product as your domain name.
• Do not use an acronym or an abbreviation as a domain name. Users may have difficulty recognizing the business unit that an acronym represents.
• Do not use the name of a business unit or of a division as a domain name. Business units and other divisions change periodically, and these domain names can be misleading or become obsolete.
• Do not use geographic names that are difficult to spell and remember.
• Avoid extending the DNS domain name hierarchy more than five levels from the root domain. You can reduce administrative costs by limiting the extent of the domain name hierarchy.
• If you are deploying DNS in a private network, and you do not plan to create an external namespace, register the DNS domain name that you create for the internal domain. Otherwise, you may find that the name is unavailable if you try to use it on the Internet, or if you connect to a network that is connected to the Internet.
 
 
Site names
We recommend that you use a valid DNS name when you create a new site name. Otherwise, your site will be available only where a Microsoft DNS server is used. For more information about valid DNS names, see the "DNS computer names" section.

Allowed characters
DNS host names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and the period (.). Period characters are allowed only when they are used to delimit the components of domain style names.
In the Windows 2000 domain name system (DNS) and in the Microsoft Windows Server 2003 DNS, the use of Unicode characters is supported. Other implementations of DNS do not support Unicode characters. Avoid Unicode characters if queries will be passed to the servers that use non-Microsoft implementations of DNS.
 
Disallowed characters
DNS host names cannot contain the following characters:• comma (,)
• tilde (~)
• colon (:)
• exclamation point (!)
• at sign (@)
• number sign (#)
• dollar sign ($)
• percent (%)
• caret (^)
• ampersand (&)
• apostrophe (')
• period (.)
• parentheses (())
• braces ({})
• underscore (_)
In DNS, a period breaks the name into a different namespace. In this scenario, such use is not valid.
The DNS host name cannot contain blank or space characters.
No distinction is made between upper and lowercase.
The first character must be alphabetical or numeric.
The last character must not be a minus sign or a period.
Minimum name length
1 character.
Maximum name length
24 characters.
The maximum length of the host name and of the fully qualified domain name (FQDN) is 63 octets per label and 255 bytes per FQDN. This maximum includes 254 bytes for the FQDN and one byte for the ending dot.
In Windows 2000 and in Windows Server 2003, the maximum host name and the FQDN use the standard length limitations that are mentioned earlier, with the addition of UTF-8 (Unicode) support. Because some UTF-8 characters exceed one octet in length, you cannot determine the size by counting the characters.
 
OU names
Allowed characters
All characters are allowed, even extended characters. However, although Active Directory Users and Computers lets you name an OU with extended characters, we recommend that you use names that describe the purpose of the OU and that are short enough to easily manage. Lightweight Directory Access Protocol (LDAP) does not have any restrictions, because the CN of the object is put in quotation marks.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
886689 (http://support.microsoft.com/kb/886689/) The Ntdsutil authoritative restore operation is not successful if the distinguished name path contains extended characters in Windows Server 2003 and in Windows 2000
Disallowed characters
No characters are not allowed.
Minimum name length
1 character.
Maximum name length
64 characters.
Special issues
When the OU has the same name as another object in the forest, a name collision may sometimes occur. We recommend that you do not give an OU the same name as another object in the forest.
 
For example, consider a scenario where the OU has the same name as other objects in the forest. An OU in the parent domain has the same name as the NetBIOS name of a child domain. The OU is deleted during the tombstone lifetime of the OU. Then, a child domain that has the same name is created, deleted, and created again. In this scenario, a duplicate object in the Jet database causes a phantom-phantom name collision when the child domain is re-created. This problem prevents the configuration container from replicating.
Table of reserved words
Reserved words for names Windows NT 4.0 Windows 2000 Windows Server 2003
NULL X X X
WORLD X X X
LOCAL X X X
CREATOR OWNER X X X
CREATOR GROUP X X X
NT DOMAIN X X X
NT AUTHORITY X X X
DIALUP X X X
NETWORK X X X
BATCH X X X
INTERACTIVE X X X
SERVICE X X X
BUILTIN X X X
SYSTEM X X X
ANONYMOUS X X X
CREATOR OWNER SERVER X X X
CREATOR GROUP SERVER X X X
SERVER  X X
SELF  X X
AUTHENTICATED USER  X X
RESTRICTED  X X
INTERNET  X X
TERMINAL SERVER  X X
PROXY  X X
LOCALSERVICE   X
NETWORKSERVICE   X
REMOTE INTERACTIVE   X
USERS   X
NTLM AUTH   X
DIGEST AUTH   X
SCHANNEL AUTH   X
THIS ORGANIZATION   X
ArchitectWindows Server 2003; Windows 2000 ServerActive Directory
Background Intelligent Transfer Service White Paper
Attachment
Background Intelligent Transfer Service (BITS) asynchronously transfers files in the foreground or background, throttles the transfers to preserve the responsiveness of other network applications, and automatically resumes file transfers after network disconnects and machine restarts.
Applications use the BITS application program interface (API) to create transfer jobs and to monitor the progress of jobs in the transfer queue. The BITS API is included in the Microsoft® Platform Software Development Kit (SDK).
This document is intended for IT professionals who are interested in using BITS from within their software.
 
 
ArchitectWindows Server 2003
Active Directory Federation Services (ADFS) in Windows Server 2003 R2
Attachment
Federated identity management is a standards-based technology and information technology process that enables distributed identification, authentication, and authorization across organizational and platform boundaries. Federated systems interoperate across organizational boundaries and connect processes utilizing different technologies, identity storage, security approaches, and programming models. Within a federated system, an organization needs a standardized and secure way of expressing not only the services it makes available to trusted partners and customers, but also the policies by which it runs its business, such as which other organizations and users it trusts, what types of credentials and requests it accepts, and its privacy policies.
The Active Directory Federation Services (ADFS) solution in Windows Server 2003 R2 helps administrators address these challenges by enabling organizations to securely share a user's identity information.
 
To read all, open or download this document!
Architect; Security ServicesWindows Server 2003; Windows 2000 ServerActive Directory
MS Management Products PPT (Novenci - JeffA)
Attachment
Novenci presentation on MS Management Products:
  • WSUS
  • SMS 2003
  • MOM 2005
  • SC SPM 2006
  • Microsoft Products Roadmap
 
 
 
Presentation PPT !
ArchitectWindows Server 2003Active Directory
Best Practices for Delegating Active Directory Administration Abstract
Delegation of administration, a key capability of Active Directory, provides a means to manage an Active Directory environment successfully. This document discusses in depth the issues that are involved in delegating administrative responsibilities, and it can help you plan for, implement, and maintain an administrative delegation model that provides secure and efficient management for Active Directory.
This document provides all the information necessary to create, implement, and maintain a security-conscious and efficient delegation model for managing your Active Directory environments. This information includes an overview of delegation, in-depth explanations of rationales for delegation, technical descriptions of how delegation works in Active Directory, processes for creating delegation models for both service management and data management, the steps needed to implement and maintain the delegation models, and a detailed case study. Appendices to this document provide an exhaustive reference, including a comprehensive list of Active Directory administrative tasks and the associated permissions that are required to delegate every administrative task in Active Directory.
 
For more information about this topic, click this link:
 
 
Architect; Plan; Security ServicesWindows Server 2003; Windows 2000 ServerActive Directory
Concepts: Windows and Security Services
Attachment
A PPT file (in french) to understand major concepts on WIndows security services.
 
 
Architect; Security ServicesWindows Server 2003; Windows 2000 ServerActive Directory
Deploying PKI Inside Microsoft
Many of the techniques and products available to help secure an enterprise network rely on some form of cryptography. A Public Key Infrastructure (PKI) provides the certificates used by each party involved in a cryptographically secured electronic transaction. To help secure the Microsoft corporate network, the Microsoft internal Information Technology group—called Microsoft IT—needed to implement several initiatives that required cryptographic techniques. These initiatives included:
• Certificate-based 802.1X wireless authentication
 
• Secure Multipurpose Internet Mail Extensions (S/MIME) for digitally signing and encrypting e-mail
 
• Encrypting File System (EFS) for file and folder encryption
 
• Internet Protocol Security (IPsec) for the security of network transactions
 
• Secure Sockets Layer (SSL) for the security of Web connections
 
• Smart cards for two-factor remote access authentication
 
These initiatives required the presence of an enterprise-wide PKI to provide public key–based security services.
Running its own certification authorities (CAs) rather than using commercial, third-party services enabled Microsoft IT to more securely manage the infrastructure and reduce the costs associated with issuing certificates and managing an external CA relationship. Implementing an enterprise PKI enabled Microsoft IT to better secure its network-based communications.
Microsoft IT’s easy-to-manage, standards-based, scalable PKI solution resulted in a method to exchange sensitive data, compatibility with other Microsoft applications, and reduced infrastructure costs.
This white paper describes the deployment and use of the PKI features of Windows server and client products into the production environment at Microsoft. Certificate Services provides customizable services for managing certificates in a PKI infrastructure, such as when creating a CA that receives certificate requests, verifying both the information in the request and the identity of the requester, issuing and revoking certificates, and publishing a Certificate Revocation List (CRL).
 
Click this link, to read all!
 
 
Architect; Security ServicesWindows Server 2003; Windows 2000 Server; WIndows XP ProfessionalActive Directory
How to secure CA private key with Windows Server 2003 and HSM modules?
A highly secure server peripheral for the management of cryptographic keys and the protection of sensitive applications
With cryptography now a fundamental component of many business-critical processes—authentication, authorization, digital signatures, time-stamping, secure transactions and more—protection of all cryptographic keys as well as the application operations themselves is vital.
That’s why so many organizations around the world have turned to nCipher’s nShield hardware security modules (HSMs) to help them strengthen their security infrastructure.
 
 
 
 
To read all on Smart Card Deployment at Microsoft, access this White paper:
 
 
Architect; Security ServicesWindows Server 2003; Windows 2000 ServerActive Directory
Implementing and Administering Certificate Templates in Windows Server 2003
Windows 2000 introduced the concept of using certificate templates to define the format and content of a certificate. Certificate templates are used by Windows 2000 Enterprise CAs to define what certificates can be issued by the Windows 2000 Enterprise CAs. Associated with the certificate template is a discretionary access control list (DACL) that defines which security principals have permissions to read, enroll, and configure the certificate template. Enterprise CAs are integrated into Active Directory. The certificate templates and the DACLs of the certificate template objects are defined in Active Directory with a forest-wide validity. If more than one Enterprise CA is running in the Windows forest, permission changes would have an impact on all Enterprise CAs.
The certificate templates used by Windows 2000 Enterprise CAs are known as version 1 certificate templates. Windows 2000 shipped with a number of predefined version 1 certificate templates, but modification of these default certificate templates is not allowed. The only modification that is enabled is the changing of permissions to allow enrollment of the certificate template. The version 1 certificate templates are created by default when an Enterprise CA is installed.
Windows Server 2003 extends certificate templates by introducing version 2 templates. Version 2 templates allow customization of most settings in the template. Several preconfigured version 2 templates are supplied in the default configuration and more can be added as necessary. This allows complete configuration flexibility for administrators. Alternatively, a version 1 certificate template can be duplicated, resulting in a version 2 certificate template that can be modified and secured separately.
Note: Similar to Windows 2000, Windows Server 2003 supports only version 1 templates. Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition support both version 1 and version 2 templates. Certificates based on version 2 templates can only be issued by an Enterprise CA running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition.
 
To read all best practices in designing, administering, and implementing version 2 Certificate Templates using Windows Server 2003, Enterprise Edition and Enterprise Certification Authorities (CAs), click this link:
 
 
Architect; Security ServicesWindows Server 2003; Windows 2000 Server; WIndows XP ProfessionalActive Directory
How to troubleshoot Exchange Server 2003 Message Security?
To resolve all certificates problems with encryption and signatures with Outlook, Exchange and Certificate Services, click this link:
 
 
Architect; Security ServicesWindows Server 2003Active Directory
Windows Server 2003 TechCenter Home / Security Services : Certificate Autoenrollment in Windows Server 2003
Microsoft Windows Server 2003, Enterprise Edition introduces the capability to automatically enroll users and computers for certificatesincluding smart cardbased certificates.
 
Using the autoenrollment feature, organizations can manage the certificate lifecycle for users, which includes:
• Certificate renewal
 
• Superseding of certificates
 
• Multiple signature requirements
 
Certificate autoenrollment is based on the combination of Group Policy settings and version 2 certificate templates. This combination allows the Windows XP Professional or Windows Server 2003 client to enroll users when they log on to their domain, or a machine when it boots, and keeps them periodically updated between these events.
Automatic enrollment of user certificates provides a quick and simple way to issue certificates to users and to enable public key infrastructure (PKI) applications, such as smart card logon, Encrypting File System (EFS), Secure Sockets Layer (SSL), Secure/Multipurpose Internet Mail Extension (S/MIME), and others, within an Active Directory directory service environment.
 
User autoenrollment minimizes the high cost of normal PKI deployments and reduces the total cost of ownership (TCO) for a PKI implementation when Windows XP Professional clients are configured to use Active Directory.
 
To read the full story, click here!
 
Architect; Security ServicesWindows Server 2003; Windows 2000 ServerActive Directory
MS Cryptographic CSP types
A starting point for the descriptions of supported algorithms:
Key Exchange : RSA
Signature  : RSA
Encryption :  RC2 / RC4 / AES 
Hashing : MD5 / SHA
 
To read all click this link:
 
  • About SHA Secure Hash Algorithm
    (SHA) A hashing algorithm that generates a message digest. SHA is used with the Digital Signature Algorithm (DSA) in the Digital Signature Standard (DSS), among other places. CryptoAPI references this algorithm by the algorithm's identifier (CALG_SHA), name (SHA), and class (ALG_CLASS_HASH). There are four varieties of SHA: SHA-1, SHA-256, SHA-384, and SHA-512. SHA-1 generates a 160-bit message digest. SHA-256, SHA-384, and SHA-512 generate 256-bit, 384-bit, and 512-bit message digests, respectively.
  • SHA was developed by the National Institute of Standards and Technology (NIST) and by the National Security Agency (NSA).
  • Secure Hash Standard
    A standard designed by NIST and NSA. This standard defines the Secure Hash Algorithm (SHA-1) for use with the Digital Signature Standard (DSS).
  • RC2 block encryption algorithm. Key length: 40 to 88 bits 
  • RC4 stream encryption algorithm. Key length: 40 to 88 bits
Architect; Security ServicesWindows Server 2003; Windows 2000 Server; WIndows XP ProfessionalActive Directory
About Cryptographic Key types and sizes
Cryptographic keys are central to cryptographic operations. They must be kept secret because whoever possesses a given key has access to any data that the key is associated with.
 
For example, if a key is used to encrypt a file, anyone with a copy of that key can decrypt the file. Furthermore, anyone possessing a key used to sign messages can forge that message's signature.

There are two types of cryptographic keys:
 
Session Keys and Public/Private Key Pairs
  • Public/Private Key Pairs

Public/private key pairs are used for asymmetric encryption. Asymmetric encryption is used mainly to encrypt and decrypt session keys and digital signatures. Asymmetric encryption uses public key encryption algorithms.


Public key algorithms use two different keys: a public key and a private key. The private key member of the pair must be kept private and secure. The public key, however, can be distributed to anyone who requests it. The public key of a key pair is often distributed by means of a digital certificate. When one key of a key pair is used to encrypt a message, the other key from that pair is required to decrypt the message. Thus if user A's public key is used to encrypt data, only user A (or someone who has access to user A's private key) can decrypt the data. If user A's private key is used to encrypt a piece of data, only user A's public key will decrypt the data, thus indicating that user A (or someone with access to user A's private key) did the encryption.
 
If the private key is used to sign a message, the public key from that pair must be used to validate the signature. For example, if Alice wants to send someone a digitally signed message, she would sign the message with her private key, and the other person could verify her signature by using her public key. Because presumably only Alice has access to her private key, the fact that the signature can be verified with Alice's public key indicates that Alice created the signature.
 
Unfortunately, public key algorithms are very slow, roughly 1,000 times slower than symmetric algorithms. It is impractical to use them to encrypt large amounts of data. In practice, public key algorithms are used to encrypt session keys.
 
Symmetric algorithms are used for encryption/decryption of most data.
 
Similarly, because signing a message in effect encrypts the message, it is not practical to use public key signature algorithms to sign large messages. Instead, a fixed-length hash is made of the message and the hash value is signed. For more details, see Hashes and Digital Signatures.
 
Each user generally has two public/private key pairs. One key pair is used to encrypt session keys and the other to create digital signatures. These are known as the key exchange key pair and the signature key pair, respectively.
 
Note that although key containers created by most cryptographic service providers (CSPs) contain two key pairs, this is not required. Some CSPs do not store any key pairs while other CSPs store more than two pairs.
 
All keys in CryptoAPI are stored within CSPs. CSPs are also responsible for creating the keys, destroying them, and using them to perform a variety of cryptographic operations.
 
Exporting keys out of the CSP so that they can be sent to other users is discussed in Cryptographic Key Storage and Exchange.

 
To read all concerning session keys, click this link!
 
 
The default CSP and default key length may change between operating system versions. It is important that both the encryption and decryption use the same CSP and that the key length be explicitly set using the dwFlags parameter to ensure interoperability on different operating system platforms.
In particular, the default RSA Full Cryptographic Service Provider is the Microsoft RSA Strong Cryptographic Provider. The default DSS Signature Diffie Hellman Cryptographic Service Provider is the Microsoft Enhanced DSS Diffie Hellman Cryptographic Provider. Each of these CSPs has a default 128-bit symmetric key length for RC2 and RC4 and a 1,024-bit default key length for public key algorithms.
 
The following table lists minimum, default, and maximum signature and exchange key lengths beginning with Windows XP.
Key type and provider Minimum length Default length Maximum length
RSA Base Provider
Signature and ExchangeKeys 384 512 16,384
RSA Strong and Enhanced Providers
Signature and Exchange Keys 384 1,024 16,384
DSS Base Providers
Signature Keys 512 1,024 1,024
DSS Base Providers
Exchange Keys Not applicable Not applicable Not applicable
DSS/DH Base Providers
Signature Keys 512 1,024 1,024
DSS/DH Base Providers
Exchange Keys 512 512 1,024
DSS/DH Enhanced Providers
Signature Keys 512 1,024 1,024
DSS/DH Enhanced Providers
Exchange Keys 512 1,024 4,096
 
The following table lists minimum, default, and maximum signature and exchange key lengths through Windows 2000.
Key type and provider Minimum length Default length Maximum length
RSA Base and Strong Providers
Signature Keys 384 512 16,384
RSA Base Provider
Exchange Keys 384 512 1,024
RSA Strong Provider
Exchange Keys 384 512 16,384
RSA Enhanced Provider
Signature and Exchange Keys 384 1,024 16,384
 
 
Architect; Security ServicesWindows Server 2003; Windows 2000 Server; WIndows XP ProfessionalActive Directory; EFS
MSDN Resources on Microsoft Cryptographic Service Providers
A Cryptographic Service Provider (CSP) contains implementations of cryptographic standards and algorithms. At a minimum, a CSP consists of a dynamic-link library (DLL) that implements the functions in CryptoSPI (a system program interface).
 
To learn more on CSP inclued in Windows Server 2003, click this link:
 
 
Architect; Security ServicesWindows Server 2003; Windows 2000 Server; WIndows XP ProfessionalActive Directory
How Microsoft does "its" security
To secure the Microsoft corporate network, the Microsoft internal Information Technology group—called Microsoft IT—needed to implement multiple technologies and services based on cryptographic techniques.
 
On this link, you'll know how MS ITG does:
  • PKI Deployment Inside Microsoft 
  • Windows Rights Management Services Deployment at Microsoft 
  • Desktop Patch Management 
  • Improve Security at Microsoft through Deployment of Windows XP Service Pack 2 
  • Improve Security on Domain Isolation with IP Security (IPsec) 
  • Incident Response-Managing Security at Microsoft
  • Messaging Hygiene at Microsoft 
  • Microsoft Helpdesk Use of Remote Assistance in Windows XP Professional 
  • Microsoft IT Attack and Penetration Testing Team  
  • Patch Management for Servers 
  • Security Enhancements for Remote Access at Microsoft 
  • Server Security Patch Management at Microsoft
  • Smart Card Deployment at Microsoft 
  • Systems Management Server 2003: Deployment at Microsoft 
  • Desktop Patch Management at Microsoft 
  • Systems Management Server 2003: How Microsoft Does Patch Management 

All theses documents are available for download here:

 
Architect; Plan; Deploy; Top IT Tasks; Case Study; Security ServicesWindows Server 2003; Windows 2000 Server; WIndows XP ProfessionalActive Directory
Deploying PKI and RMS Inside Microsoft
Detailed discussion of how Microsoft IT installed a Public Key Infrastructure, built originally with Windows 2000 Server Certificate Services and later upgraded with Windows Server 2003, to implement a secure communications and remote authentication infrastructure. This enabled the use of S/MIME signatures and encryption, secured Web connections by using SSL or TLS, ensured the confidentiality of stored data by using EFS, ensured the confidentiality and integrity of transmitted date by using IPSec, and enabled strong network user authentication by using Smart Cards.
 
 
 
Architect; Plan; Deploy; Security ServicesWindows Server 2003; Windows 2000 ServerActive Directory
How to control Windows Firewall Settings for Microsoft Windows XP with Service Pack 2?
Although Group Policy is the recommended and easiest method to deploy Windows Firewall settings for computers running Windows XP with SP2, there are situations in which this method is not possible or not used. For example, an environment that uses Windows NT® 4.0 domains or that uses workgroups cannot use Active Directory and Group Policy to propagate Windows Firewall settings to multiple computers on an organization network.
 
Another example is an organization that uses Active Directory, but does not use Group Policy to centrally configure user or computer configuration settings.
 
For more information about deploying Windows Firewall settings in your enterprise, please, click this link:
 
 
To learn more, download this white paper! This document describes how to deploy the appropriate configuration settings for Windows Firewall on an organization network so that it is enabled and providing protection, and so that needed communications are not impaired.
 
 
 
Architect; Plan; Deploy; Security ServicesWindows Server 2003; WIndows XP ProfessionalActive Directory
Upgrading from Windows NT Server 4.0
Attachment
This document provides an overview of the upgrade process and provides information on some of the basic decisions you will make during the process—whether upgrading an existing system, or performing a new installation. This document also provides pointers to the complete set of documents, including Getting Started and the onscreen Help and Support Center that provide detailed instructions on moving from Windows NT Server 4.0 to Windows Server 2003.
Architect; Plan; DeployWindows Server 2003; Windows 2000 ServerActive Directory
Windows 2000 Auditing and Intrusion Detection
It is not sufficient to simply put secure systems in place to maintain a truly secure environment. It is a dangerous assumption that either you will not be attacked, or that your defenses will adequately protect you.
 
To maintain the security of your systems it is also necessary to actively monitor for intrusion and attack.
There are a number of reasons why monitoring and auditing for intrusion are very important.
 
These include:
• Any functional computer environment is potentially open to attack. No matter how high your level of security, there is a risk that you may be attacked.
 
• Successful attacks often follow a series of unsuccessful ones. If you do not monitor for attacks you will not detect intruders before they are successful.
 
• Once a successful attack occurs, the earlier you find out, the easier it will be to contain the damage.
 
• In order to recover from an attack, you need to know what damage has been done.
 
• Auditing and intrusion detection helps you determine who was responsible for the attack.
 
• The combination of auditing and intrusion detection helps correlate information to identify attack patterns.
 
• Regular review of security logs helps identify unknown security configuration issues, such as incorrect permissions, or lax account lockout settings.
 
• After an attack is detected, auditing can assist in determining what network resources are compromised.
 
 
Objectives
Use this module to:
• Implement auditing in your organization using best practices.
 
• Protect key log files and prevent attackers from interfering with evidence.
 
• Combine passive and active detection methods.
 
• Identify which tools and technologies need to be made available to surveillance and monitoring staff, and how they will be used in the auditing process.
 
To download the complete solution, clickk this link:
 
To access all web content, click this link:

 

 

 

ArchitectWindows Server 2003Active Directory
Windows Server 2003 Security Guide
The material explains the different requirements to secure three distinct environments, as well as what each prescribed server setting addresses in terms of client dependencies. The three environments considered are called Legacy Client, Enterprise Client, and High Security.
• The Legacy Client settings are designed to work in an Active Directory domain running on Windows Server 2003 domain controllers with Windows 98, Windows NT 4.0, and later client computers and member servers.
 
• The Enterprise Client settings are designed to work in an Active Directory domain running on Windows Server 2003 domain controllers with Windows 2000, Windows XP, and later client computers and member servers.
 
• The High Security settings are also designed to work in an Active Directory domain running on Windows Server 2003 domain controllers with Windows 2000, Windows XP, and later client computers and member servers. However, the High Security settings are so restrictive that many applications may not function, performance of the servers may be noticeably slower, and managing the servers will be more challenging.
 
See full-sized image.

These levels of hardening guidance are provided for a baseline member server as well as a group of distinct server roles. The documents included as part of this guidance are discussed below.
 
To download, click this link,
 
Architect; Plan; Deploy; Security ServicesWindows Server 2003Active Directory
ADS Training Kit Module 7: Windows Security and PKI concepts
Attachment
Download this to learn more on Windows security and PKI fondamentals. This document is in French.
 
Architect; Security ServicesWindows Server 2003
Group Policy Infrastructure White Paper
Attachment
Intended for system administrators, architects, and others who need to create and manage Group Policy settings, this paper explains Group Policy infrastructure and shows how Group Policy Management Console (GPMC), a new MMC snap-in with scripting interfaces, fits into this infrastructure.
 
 
 
 
Administrators use Group Policy to specify managed configurations for groups of computers and users. Group Policy includes options for registry-based policy settings, security settings, software installation, scripts, folder redirection, Remote Installation Services, and Internet Explorer maintenance. Intended for system administrators, architects, and others who need to create and manage Group Policy settings, this paper explains Group Policy infrastructure and shows how Group Policy Management Console (GPMC), a new MMC snap-in with scripting interfaces, fits into this infrastructure. The paper includes detailed information about Group Policy processing as well as many best practices useful to the Group Policy administrator.
 
 
ArchitectWindows Server 2003; Windows 2000 Server; WIndows XP Professional; Windows 2000 ProfessionalActive Directory
Security Screen Savers
Attachment
A cool screen saver for security best practices... from MS
 
 
Deploy; Security ServicesWindows Server 2003; Windows 2000 Server; WIndows XP Professional; Windows 2000 Professional
Discover How Siemens Manages 340,000 Desktops!
Attachment
Today, Siemens has 417,000 people, 340,000 desktops, and 8,900 servers in 130 business units in 190 countries. A few years ago, Siemens supported its business with 1,000 domains in a highly decentralized structure.
 
It wanted a single, centralized Active Directory to streamline user management, e-mail, and collaboration. Siemens was also developing an Entitlement Architecture based on a Siemens DirX solution for its corporatewide Identity Management infrastructure.
 
Architect; Collaboration; Plan; Case StudyWindows Server 2003Active Directory
Optimizing Size Requirements for Growth in Directory Service
Please, read this MS link to learn more on Active Directory sizing.
 
 
 
ArchitectWindows Server 2003Active Directory
All tasks to deploy the Active Directory (French MPP file)
Attachment
This Microsoft Project 2003 file describes all tasks and actions required to design, plan and deploy the Active Directory Service...
 
A good starting point to begin the work...
Architect; Plan; DeployWindows Server 2003; Windows 2000 ServerActive Directory
Windows 2003 Active Directory : Différences avec Windows 2000 Server.
Attachment
Ce document Microsoft  en format PDF décrit de manière détaillée toutes les différences qui existent entre Microsoft Windows Server 2003 et Microsoft Windows 2000.
Ce document est particulièrement axé sur les services d'annuaire Active Directory.
 
 
 
 
Architect; Plan; Deploy; Support; Top IT Tasks; Case Study; Security ServicesWindows Server 2003; Windows 2000 ServerActive Directory
PPT: How Microsoft Does Patch Management Using Microsoft Systems Management Server 2003
Attachment
This 30-minute multimedia presentation, published January 2004, discusses how Microsoft IT patches its desktop and server environment using Microsoft Systems Management Server (SMS) 2003. 
 
Microsoft IT turned to SMS 2003 to manage the application deployment process, improve hardware and software asset management, and to manage the deployment of security and software updates across the enterprise.
Microsoft IT’s lessons learned and best practices for using SMS 2003 for desktop and server patch management.
This multimedia presentation is intended for enterprise technical decision makers who want to gain a better understanding of the processes and implementation of SMS 2003 for patch management. This multimedia presentation does not include a detailed discussion of the SMS 2003 feature set.
Architect; Plan; Deploy; SupportWindows Server 2003; Windows 2000 Server; WIndows XP Professional; Windows 2000 ProfessionalActive Directory
RFC 3279: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure
Attachment

Network Working Group
Request for Comments: 3279
Obsoletes: 2528
Category: Standards Track 
W. Polk - NIST
R. Housley - RSA Laboratories
L. Bassham - NIST
April 2002

Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

 

Table of Contents

  • 1 Introduction
  • 2 Algorithm Support
  • 2.1 One-Way Hash Functions
  • 2.1.1 MD2 One-Way Hash Functions
  • 2.1.2 MD5 One-Way Hash Functions
  • 2.1.3 SHA-1 One-Way Hash Functions
  • 2.2 Signature Algorithms
  • 2.2.1 RSA Signature Algorithm
  • 2.2.2 DSA Signature Algorithm
  • 2.2.3 Elliptic Curve Digital Signature Algorithm
  • 2.3 Subject Public Key Algorithms
  • 2.3.1 RSA Keys
  • 2.3.2 DSA Signature Keys
  • 2.3.3 Diffie-Hellman Key Exchange Keys
  • 2.3.4 KEA Public Keys
  • 2.3.5 ECDSA and ECDH Public Keys
  • 3 ASN.1 Module
  • 4 References
  • 5 Security Considerations
  • 6 Intellectual Property Rights
  • 7 Author Addresses

Copyright Notice - Copyright (C) The Internet Society (2002). All Rights reserved.

Click the link bellow to see the full RFC or connect to http://www.rfc-editor.org/ and search in the RFC database 3279

 

 

Architect; Security ServicesWindows Server 2003; Windows 2000 ServerActive Directory
Upgrading from Microsoft Exchange Server 5.5 to Microsoft Exchange 2000 Server: A Six-Step Case Scenario
Attachment

This article provides a Microsoft Exchange 2000 Server deployment case scenario for an imaginary company.

This article guides you through the following six steps of an Exchange deployment:

  1. Create a detailed deployment plan.
  2. Begin a successful deployment of Microsoft Windows 2000.
  3. Prepare Active Directory directory service and Exchange directories.
  4. Install your first Exchange 2000 server.
  5. Upgrade the information stores and other Exchange components.
  6. Switch to Exchange native mode.

The purpose of this article is to provide you with a clear picture of upgrading from Exchange 5.5