Posts Tagged ‘Server’
Active Directory Intersite Replication
Posted: July 5, 2011 in Active Directory, Server, Server 2003, Server 2008Tags: Active Directory, Server, Server 2003, Server 2008
What is ADSIEdit?
Posted: July 5, 2011 in Active Directory, Server, Server 2003Tags: Active Directory, Server, Server 2003
ADSIEdit is a Microsoft Management Console (MMC) snap-in that acts as a low-level editor for Active Directory. It is a Graphical User Interface (GUI) tool. Network administrators can use it for common administrative tasks such as adding, deleting, and moving objects with a directory service. The attributes for each object can be edited or deleted by using this tool. ADSIEdit uses the ADSI application programming interfaces (APIs) to access Active Directory. The following are the required files for using this tool:
ADSIEDIT.DLL
ADSIEDIT.MSC
Regarding system requirements, a connection to an Active Directory environment and Microsoft Management Console (MMC) is necessary.
Determine the tombstone lifetime for the forest
Posted: July 5, 2011 in Active Directory, Server, Server 2003Tags: Active Directory, Server, Server 2003
The tombstone lifetime is determined by the value of the tombstone Lifetime attribute on the Directory Service object in the configuration directory partition.
Administrative Credentials
To complete this procedure, you must be a member of the Domain Users group.
To determine the tombstone lifetime for the forest
1. On the Start menu, click Run, type adsiedit.msc, and then click OK.
2. In the console tree, double-click Configuration [DomainControllerName], CN=Configuration,DC=[ForestRootDomain], CN=Services, and CN=Windows NT.
3. Right-click CN=Directory Service, and then click Properties.
4. In the Attribute column, click tombstoneLifetime.
5. Note the value in the Value column. If the value is <not set>, the default value is in effect as follows:
• On a domain controller in a forest that was created on a domain controller running Windows Server 2003 with Service Pack 1 (SP1), the default value is 180 days.
• On a domain controller in a forest that was created on a domain controller running Windows 2000 Server or Windows Server 2003, the default value is 60 days.
Support Files of Active Directory
Posted: July 5, 2011 in Active Directory, Server, Server 2003, Server 2008Tags: Active Directory, Server, Server 2003, Server 2008
The Active Directory support files are listed below. These are the files that you specify a location for when you promote a server to a domain controller:
- Ntds.dit (NT Directory Services): Ntds.dit is the core Active Directory database. This file on a domain controller lists the naming contexts hosted by that particular domain controller.
- Edb.log: The Edb.log file is a transaction log. When changes occur to Active Directory objects, the changes are initially saved to the transaction log before they are written to the Active Directory database.
- Edbxxxxx.log: This is auxiliary transaction logs that can be used in cases where the primary Edb.log file fills up prior to it being written to the Ntds.dit Active Directory database.
- Edb.chk: Edb.chk is a checkpoint file that is used by the transaction logging process.
- Res log files: These are reserve log files whose space is used if insufficient space exists to create the Edbxxxxx.log file.
- Temp.edb: Temp.edb contains information on the transactions that are being processed.
Schema.ini: The Schema.ini file is used to initialize the Ntds.dit Active Directory database when a domain controller is promoted.
Supported Upgrade Paths for Server 2008
Posted: June 30, 2011 in Server, Server 2008, System InformationTags: Server, Server 2008
Before performing an upgrade, you should make sure the server’s installed software and hardware support Windows Server 2008. You can download tools for testing compatibility and documentation at the Windows Server Catalog Web site (http://www.windowsservercatalog.com/).
Microsoft Server operating systems from Windows 2000 and later can be upgraded to Windows Server 2008. In general, servers can be upgraded to a product with equal or greater capabilities, thus:
- Windows Server 2003 Standard or Enterprise editions can be upgraded to Standard or Enterprise editions of Windows Server 2008.
- Windows Server 2003, Datacenter Edition, can be upgraded to Windows Server 2008 Datacenter.
- Windows Server 2003, Web Edition, can be upgraded Windows Web Server 2008.
- Windows Server 2008 Standard can be upgraded to Enterprise or Datacenter editions of Windows Server 2008.
- Windows Server 2008 Enterprise can be upgraded to Windows Server 2008 Datacenter.
What a firewall doesn’t protect against
Posted: June 29, 2011 in Firewall, Networking, System InformationTags: Firewall, Server
It’s important to understand that a firewall alone is not sufficient protection against all Internet threats.
A firewall is just one component in a larger defense system. Specifically:
- Windows firewall doesn’t protect you from spyware and viruses. See Chapter 8 for more information on that protection.
- Windows firewall doesn’t protect you from attacks based on exploits. Automatic updates provide that protection.
- A firewall doesn’t protect you from pop-up ads.
- A firewall doesn’t protect you from phishing scams.
- Windows firewall doesn’t protect you from spam (junk e-mail).
So, a firewall isn’t a complete solution. Rather, it’s an important component of a larger security strategy.
Windows Server 2008 Auditing Overview
Posted: June 21, 2011 in Active Directory, Server, Server 2008, System InformationTags: Active Directory, Server, Server 2008
Windows Server 2008 provides several categories of events that you can audit, as described in the following list:
■ Account Logon Events: Track user logon and logoff via a user account.
■ Account Management: Track when a user account or group is created, changed, or
deleted; a user account is renamed, enabled, or disabled; or a password is set or changed.
■ Directory Service Access: Track access to Active Directory.
■ Logon Events: Track nonlocal authentication events such as network use of a resource or a remote
service that is logging on by using the local system account.
■ Object Access: Track when objects are accessed and the type of access performed—for example,
track use of a folder, file, or printer. Configure auditing of specific events through the object’s
properties (such as the Security tab for a folder or file).
■ Policy Change: Track changes to user rights or audit policies.
■ Privilege Use: Track when a user exercises a right other than those associated with logon and
logoff.
■ Process Tracking: Track events related to process execution, such as program execution.
■ System Events: Track system events such as restart, startup, shutdown, or events that affect
system security or the security log.
Data Source Name – DSNs
Posted: June 17, 2011 in Active Directory, Server 2008, System InformationTags: Active Directory, Server, Server 2008
You make data sources available to clients by creating a Data Source Name (DSN). Three types of DSNs exist:
> User. A user DSN is visible only to the user who is logged on when the DSN is created.
> System. A system DSN is visible to all local services on a computer and all users who log on locally to the computer.
> File. A file DSN can be shared by all users who have the same drivers installed and who
have the necessary permissions to access the DSN. Unlike user and system DSNs, file
DSNs are stored in text files, rather than the registry.
The DSN identifies the data source, the driver associated with a data source, and other properties that define the interaction between the client and the data source, such as timeout, read-only mode, and so on. You use the same process to create a DSN for most database types. The exception is SQL Server, which provides a wizard for setting up a data source.
Defining a data source
To create a data source, you first open the ODBC Data Source Administrator. To do so, click Start _ All Programs _ Administrative Tools _ Data Sources (ODBC). In the ODBC Data Source Administrator, click the tab for the DSN type you want to create and then click Add. Select the desired data source type and click Finish. Except in the case of the SQL Server driver, ODBC prompts you for information, which varies according to the driver selected. Define settings as desired and click OK to create the DSN.
Blade Servers
Posted: June 3, 2011 in Active Directory, Server, Server 2003, Server 2008Tags: Server, Server 2003
Blade computing introduces a new data center paradigm where various thin compute blades share centralized resources in a single chassis. Ablade server is a single circuit board populated with components such as memory, processors, I/O adapters, and network connections that are often found on multiple boards. Server blades are built to slide into existing servers. They are smaller, need less power, and are more cost-efficient than traditional box-based servers.
Managing these servers requires the following:
- A virtualized view of the servers and resources it uses (such as storage)
- A high level of security within the server and on the network devices
- Dynamic resource provisioning that is automated as much as possible
- A layout that is easy to scale to meet ever-increasing user demands
Data centers will realize a shift from box-based servers to densely packed racks of blade-based servers.
Smart Card Deployment Considerations
Posted: June 1, 2011 in Active Directory, Server, Server 2003, System InformationTags: Active Directory, Server, Server 2003
Smart card logon is supported for Windows 2000 and Windows Server 2003. To implement smart cards, you must deploy an enterprise certification authority rather than a stand-alone or third-party certification authority to support smart card logon to Windows Server 2003 domains. Windows Server 2003 supports industry standard Personal Computer/Smart Card (PC/SC)–compliant smart cards and readers and provides drivers for commercially available plug and play smart card readers. Windows Server 2003 does not support non-PC/SC-compliant or non–plug and play smart card readers. Some manufacturers might provide drivers for non–plug and play smart card readers that work with Windows Server 2003; however, it is recommended that you purchase only plug and play PC/SC-compliant smart card readers.
The cost of administering a smart card program depends on several factors, including:
■ The number of users enrolled in the smart card program and their location.
■ Your organization’s practices for issuing smart cards to users, including the requirements for verifying user identities. For example, will you require users to simply present a valid personal identification card or will you require a back-ground investigation? Your policies affect the level of security provided as well as the actual cost.
■ Your organization’s practices for users who lose or misplace their smart cards. For example, will you issue temporary smart cards, authorize temporary alternate logon to the network, or make users go home to retrieve their smart cards? Your policies affect how much worker time is lost and how much help desk support is needed.
Your smart card authentication strategy must describe the network logon and authentication methods you use, including:
■ Identify network logon and authentication strategies you want to deploy.
■ Describe smart card deployment considerations and issues.
■ Describe PKI certificate services required to support smart cards.
In addition to smart cards, third-party vendors offer a variety of security products to provide two-factor authentication, such as “security tokens” and biometric accessories. These accessories use extensible features of the Windows Server 2003 graphical logon user interface to provide alternate methods of user authentication.

