CTX105955 – How to Check In a User Dump that Full Page Heap was Enabled – Citrix Knowledge Center

Summary

Technical Support may ask customers to enable full page heap on specific Citrix executable files such as ImaSrv.exe to troubleshoot heap corruption issues.

However, customers sometimes think they have enabled full page heap, but in fact they did not.

Technical Support needs to check that the user dump sent was generated when full page heap was enabled.

Procedure

1. Open WinDbg.
2. Verify that File\Symbol File Path… dialog contains the path to Microsoft Symbol Server:
   srv*c:\symdownstream*http://msdl.microsoft.com/download/symbols
3. Open the dump and execute the following command:
   !gflag
4. Check the output:

0:001> !gflag
Current NtGlobalFlag contents: 0×02000000
hpa – Place heap allocations at ends of pages

“0×02000000” means GlobalFlags are enabled, so you are looking at a full page heap dump.

“0×00000000” means GlobalFlags are not enabled.

More Information

CTX104633 – How to Enable Full Page Heap for the IMA Service

This document applies to:

• MetaFrame Presentation Server 3.0 for Microsoft Windows 2000
• MetaFrame Presentation Server 3.0 for Microsoft Windows 2003
• MetaFrame XP 1.0 for Microsoft Windows 2000
• MetaFrame XP 1.0 for Microsoft Windows 2003
• Presentation Server 4.0 for Microsoft Windows 2000
• Presentation Server 4.0 for Microsoft Windows 2003
• Presentation Server 4.5 for Windows Server 2003
• XenApp 5.0 for Windows Server 2003 x86

Source: CTX105955 – How to Check In a User Dump that Full Page Heap was Enabled – Citrix Knowledge Center

Applying for Passport Online via Passport Seva Project Web Site

Manage Appointment:

One has to remain logged into the portal at least 30 minutes before otherwise the current online portal doesn’t accept logins just at the start of the schedule.

 

The appointment schedule would be released every day at 6 PM and will be served as First Come First Serve basis. There would be no schedules released on Thursday and Friday.

Sample message you may see:

Currently no appointment slots are available for the selected Passport Seva Kendra (PSK). Please try scheduling an appointment from 31/12/2011, 6:00 PM onwards.

 

Attending Passport Seva Kendra (PSK) :

1. You need to be at the 30 mins before the appointment.  At the PSK center you will be asked to stand in queue to get into the Token issue counters lobby
2. There would be #4 counters
   1. counter#1 for senior citizens and infants/children
   2. counter#2 and counter#3 for general age people
   3. counter#4 for Tatkal users
   4. for other priority customers, they need to speak to one of the persons at any of the counters
3. At the token issuing counters
   1. You need to show up the “Xerox and Original” all the documents that you uploaded online
   2. You need to sign on all the Xerox copies of the proof you are submitting.
   3. You need to put the date on all the Xerox copies of the proof you are submitting.
4. Once the token issuing executive verifies your proofs they will create a file for you and gives you a Token along with the file containing the verified proof
5. With the File and Token you need to enter into the Passport Processing Waiting Lobby
6. The passport processing involves getting through Three verification sections called up as A, B, C sections.
7. There will be displays showing up current Token and CSE (customer service Executive) counters
8. Once your token is called up on the screen, you need to reach to the appropriate CSE counter
9. At the Section A counter,
   1. you will be shown up your application in the computer and you need to verify that all the details there are correct and ask for any changes if needed.
   2. They will take a photo of you. So dress properly as that photograph will appear in your passport
   3. you need to pay the Passport Processing Fee in cash only (currently they accepting cash only though they are supposed to take credit/debit cards as well).
   4. You need to pay the whole fee at once.
   5. They will give you a Fee Receipt
   6. They will upload all the proof and other documents that you provided into the online portal of their software
   7. They will give you the Token slip along with fee receipt
   8. This whole process takes around #10 to #15 minutes only.
10. You need to wait at the Section B token counters, once your token is called up on the screen, you need to reach to the appropriate CSE counter
11. At the Section B counter,
    1. Provide your token and File
    2. You need to show up the Originals of your proofs
    3. Once they found them matching you can leave the counter
    4. This check takes just #5 minutes only.
12. You need to wait at the Section C token counters, once your token is called up on the screen, you need to reach to the appropriate CSE counter

13. At the Section C counter,

    1. Provide your token and File
    2. You need to show up the Originals of your proofs
    3. Once they found them matching you can leave the counter
    4. This check takes not even #5 minutes.
14. Then at the exit counter
    1. you need to provide the slips you have
    2. they will take one of the form from the slip
    3. they will provide the Acknowledge Letter
    4. The exit counter person which tell you the estimated time for receiving the passport
    5. For Normal Fresh passport – 20-25 days
15. Then you can check your passport status in Online portal
16. You would receive an email/sms once the passport is dispatched.

Important Notes/Facilities:

1. In case, you have any issue with submitting your proofs, you can do the same at any time in three days from the time of your Appointment.
2. If your token processing is not completed on that day due to more rush or technical issues, you’ll be asked to visit the PSK center next
3. Cell Phones are allowed inside
4. Other people along with applicant are allowed inside
5. Cameras (exclude cell phones), laptops and any other suspicious things are not allowed
6. There will be a Xerox counter inside the Token Issuing Lobby
7. There is a retail snack items counter that sell items at MRP cost only

 

Available Passport Seva Kendras in Hyderabad:

Passport Seva Project: Process Flow

 

Source: Passportindia.gov.in

The database ‘%.*ls’ cannot be opened because it is version %d. This server supports version %d and earlier. A downgrade path is not supported.

Details

Product:
SQL Server

ID:
948

Source:
MSSQLServer

Version:
10.0

Component:
SQLEngine

Message:
The database ‘%.*ls’ cannot be opened because it is version %d. This server supports version %d and earlier. A downgrade path is not supported.

Explanation

Certain features in SQL Server affect the structure of the database files. When you attach a database to another instance of SQL Server, the file format might not be compatible with a different version of the Database Engine.

For example, this error can be caused by using the vardecimal storage format in a later version of SQL Server and then trying to attach the database files in a version earlier than SQL Server 2005 Service Pack 2.

User Action

Determine the version of SQL Server that is running on the originating server. In SQL Server Management Studio, either right-click the server and then click Properties or type SELECT @@VERSION in a query window. Open the database by using the original version of SQL Server. Investigate the features that are enabled on the original database in the instance of SQL Server. Modify these settings to work with the version of SQL Server in which the database will be attached.

Version:
9.0

Component:
SQLEngine

Message:
The database ‘%.*ls’ cannot be opened because it is version %d. This server supports version %d and earlier. A downgrade path is not supported.

Explanation

Certain features in SQL Server affect the structure of the database files. When you attach a database to another instance of SQL Server, the file format might not be compatible with a different version of the Database Engine.

For example, this error can be caused by using the vardecimal data type in a later version of SQL Server and then trying to attach the database files in a version earlier than SQL Server 2005 Service Pack 2.

User Action

Determine the version of SQL Server that is running on the originating server. In SQL Server Management Studio, either right-click the server and then click Properties or type SELECT @@VERSION in a query window. Open the database by using the original version of SQL Server. Investigate the features that are enabled on the original database in the instance of SQL Server. Modify these settings to work with the version of SQL Server in which the database will be attached.

---

Source: MSSQLServer ID: 948 (SQL Server ) – Events And Errors Message Center: Message Details

SQL Query to get the MS SQL server version

SQL Query:

SELECT @@VERSION

Results:

 

(No column name)

Microsoft SQL Server 2008 (SP3) – 10.0.5500.0 (X64) Sep 21 2011 22:45:45 Copyright (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: )

 

An Introduction to SQL Server Service Broker

Contents

Introduction
Queues
Dialogs
Conversation Groups
Activation
Why Use Asynchronous, Queued Messaging?
Why Use Transactional Messaging?
How Service Broker Solves the Hard Problems in Messaging
Message Ordering
Coordination
Multithreading
Receiver Management
Why Build Messaging into the Database?
Conversation Group Locking
Remote Transactional Receive Handling
Common Administration
Direct Sends to Receive Queue
Common Language Support
Single-Connection Execution Capability
Enhanced Security
Transmission Queue Visibility Across Databases
Conclusion

Introduction

With Service Broker, a feature in Microsoft SQL Server 2005, internal or external processes can send and receive guaranteed, asynchronous messages by using extensions to Transact-SQL Data Manipulation Language (DML). Messages can be sent to a queue in the same database as the sender, to another database in the same SQL Server instance, or to another SQL Server instance either on the same server or on a remote server.

To better understand Service Broker, familiarity with the key concepts of queues, dialogs, conversation groups, and activation is helpful. These are discussed briefly in this section.

Queues

Service Broker uses queues to provide loose coupling between the message sender and the message receiver. The sender can use the SEND command to put a message in a queue and then continue on with the application, relying on Service Broker to ensure that the message reaches its destination.

Queues permit a lot of scheduling flexibility. For example, the sender can send out multiple messages for multiple receivers to process in parallel. The receivers might not process the messages until long after they were sent, but because incoming messages are queued, the receivers can process them at their own rate and the sender doesn’t have to wait for the receivers to finish before continuing.

Dialogs

Service Broker implements dialogs, which are bidirectional streams of messages between two endpoints. All messages in a dialog are ordered, and dialog messages are always delivered in the order they are sent. The order is maintained across transactions, across input threads, across output threads, and across crashes and restarts. Some message systems ensure message order for the messages sent or received in a single transaction but not across multiple transactions, making Service Broker dialogs unique in this regard.

Each message includes a conversation handle that uniquely identifies the dialog that is associated with it. For example, an order entry application might have dialogs open simultaneously with the shipping application, the inventory application, and the billing application. Because messages from each application have a unique conversation handle, it’s easy to tell which application sent each message.

Conversation Groups

Service Broker provides a way of grouping all the dialogs that are used for a particular task. This method uses conversation groups. In our previous order entry example, all the dialogs associated with processing a particular order would be grouped into a single conversation group. The conversation group is implemented as a conversation group identifier, which is included with all messages in all dialogs contained in the conversation group. When a message is received from any of the dialogs in a conversation group, the conversation group is locked with a lock that is held by the receiving transaction. For the duration of the transaction, only the thread that holds the lock can receive messages from any of the dialogs in the conversation group. This makes our order entry application much easier to write because even though we use many threads for scalability, any particular order is only processed on one thread at a time. This means we don’t have to make our application resilient to problems that are caused by the simultaneous processing of a single order on multiple threads.

One of the most common uses for the conversation group identifier is to label the state that is associated with a particular process. If a process involves many messages over time, it probably doesn’t make sense to keep an instance of the application running through the whole process. For example, the order entry application will scale better if, between messages, any global state that is associated with processing an order is stored in the database and retrieved when the next message associated with that order is received. The conversation group identifier can be used as the primary key in the state tables to enable quick retrieval of the state associated with each message.

Activation

You use the activation feature of Service Broker to specify a stored procedure that will handle messages destined for a particular service. When messages arrive for a service, Service Broker checks whether there is a stored procedure running that can process the messages. If there isn’t a running message-processing stored procedure, Service Broker starts one. The stored procedure then processes messages until the queue is empty, after which it terminates. Moreover, if Service Broker determines that messages are arriving faster than the stored procedure can process them, it starts additional instances of the stored procedure until enough are running to keep up with the incoming messages (or until the configured maximum number is reached). This ensures that the right number of resources for processing incoming messages are always available.

Why Use Asynchronous, Queued Messaging?

Queues enable the flexible scheduling of work, which can translate to big improvements in both performance and scalability. To see how, go back to the order entry example. Some parts of an order must be processed before the order can be considered complete, such as the order header, available to promise, and order lines. But other parts realistically don’t have to be processed before the order is committed; for example, billing, shipping, inventory, and so on. If the "delayable" piece of the order can be processed in a guaranteed but asynchronous manner, the core part of the order can be processed faster.

Asynchronous messaging can also provide opportunities for increased parallelism. For example, if you need to check the customer’s credit and check availability for ordered items, starting both processes simultaneously can improve overall response time.

Queuing can also enable systems to distribute processing more evenly, reducing the peak capacity required by a server. For example, a typical incoming order rate might look something like this:

Figure 1

There is a peak at the beginning of the day and another one at the end. If each order is entered into the shipping system as it is created, the shipping system’s load would look like this:

Figure 2

The afternoon peak is bigger because that’s when the shipping paperwork is done for outgoing shipments. If the shipping system is connected to the order entry system with a queue, the peaks can be leveled by shifting some of the work to the slack incoming order times:

Figure 3

Why Use Transactional Messaging?

Service Broker supports transactional messaging, which means that messages are sent and received as transactions. If a transaction fails, the message sends and receives are rolled back, and don’t take effect until the transaction has processed the messages successfully and committed.

Transactional messaging makes programming a messaging application much more straightforward because you can freely scatter sends and receives wherever they make sense and nothing happens until the transaction commits. If the transaction gets rolled back, none of the sends take place, and the messages that were received go back in the queue so they will be received and processed again.

How Service Broker Solves the Hard Problems in Messaging

Messaging applications have been around for a long time, and there are compelling reasons to build them. So why aren’t there more of them? The answer is that messaging applications are hard to get right. SQL Server Service Broker, however, solves some of the most difficult messaging application issues: message ordering, coordination, multithreading, and receiver management.

Message Ordering

In traditional reliable messaging applications, it’s easy to get messages delivered out of order. For example, application A sends messages 1, 2, and 3. Application B receives and acknowledges 1 and 3, but experiences an error with 2, so application A resends it. However, now 2 is received after 3. Traditionally, programmers dealt with this problem by writing the application so that order didn’t matter, or by temporarily caching 3 until 2 arrived so the messages could be processed in order. In contrast, Service Broker handles this transparently, so all messages in a dialog are received in the order sent, with no gaps in the message sequence.

A related problem is duplicate delivery. In the previous example, if application B received message 2, but the acknowledgement message back to application A was lost, application A would resend 2 and application B would now receive 2 twice. Again, Service Broker ensures that messages are never delivered twice, even if the power is lost in the middle of a transaction.

Coordination

Messages are generally stand-alone entities, which can make it difficult to determine which conversation a message came from. For example, you may send thousands of messages to an inventory service requesting inventory updates. The inventory service may respond to some of these messages almost immediately and take a very long time to respond to others, making it difficult to decide which response message corresponds to which inventory request.

With Service Broker, by contrast, both the dialog handle and the conversation group identifier are included with every message, making it very easy to determine the order and request that each response goes with. (Some messaging systems have a correlation ID you can set to make this determination, but with dialogs, this is not necessary.)

Multithreading

One of the most difficult issues in a messaging application is making a multithreaded reader work correctly. When multiple threads are receiving from the same queue, it’s always possible for messages to get processed out of order, even if they are received in order. For example, if a message containing an order header is received by thread A and a message containing an order line is later received by thread B, it’s possible that the order line transaction will attempt to commit first and fail a referential constraint because the order doesn’t exist yet. Although the order line message will roll back until the order header exists, it is still a waste of resources.

Service Broker solves multithreading issues by putting a lock on the conversation group when a message is read, so that no other thread can receive associated messages until the transaction commits. Service Broker makes multithreaded readers work simply and reliably.

Receiver Management

In many reliable messaging systems, the application that receives messages from a queue must be started before messages are received. In most cases, the user must decide how many application instances or threads should be running in each queue. If this is a fixed number and the message arrival rate varies, there are either too many or too few queue readers running most of the time.

Service Broker solves receiver management issues by activating queue readers as required when messages arrive. Moreover, if a reader crashes or the system is rebooted, readers are automatically started to read the messages in the queue. Service Broker does many of the same kinds of application management tasks that are typically handled by a middle-tier transaction-processing monitor.

Why Build Messaging into the Database?

Why is Service Broker part of the database engine? Wouldn’t it work as well if it were an external application that used the database to store its messages? There are several reasons why the database is the right place for Service Broker to be.

Conversation Group Locking

Service Broker makes multiple queue readers possible by locking the conversation group; however, locking the conversation group with normal database commands is almost impossible to accomplish efficiently. Service Broker accordingly uses a new kind of database lock, and only Service Broker commands understand this lock type.

Remote Transactional Receive Handling

Some messaging systems restrict transactional messaging to receiving applications that are running on the same server as the queue. Service Broker, by contrast, supports remote transactional receives from any server that can connect to the database.

Common Administration

One of the issues with transactional messaging systems is that if the messages are stored in a different place than the data, it’s possible for the message store and the database to get out of synch when one or the other is restored from backup. With a single database for both messages and application data in Service Broker, this is very hard to get wrong. When your data, messages, and application logic are all in the database, there is only one thing to back up, one place to set up security, and one thing to administer.

Direct Sends to Receive Queue

Because Service Broker is integrated into the database engine, a message that is addressed to another queue in any database in the same SQL Server instance can be put directly into the receive queue, bypassing the send queue and greatly improving performance.

Common Language Support

The messaging part of an application and the data part of an application use the same language and tools in a Service Broker application. This leverages the developer’s familiarity with Microsoft ActiveX Data Objects (ADO) and other database programming techniques for message-based programming. With the CLR (common language runtime) stored procedures available in SQL Server 2005, stored procedures that implement a Service Broker service can be written in a variety of languages and still take advantage of the common administration benefits of Service Broker.

Single-Connection Execution Capability

Service Broker commands can be executed over the same database connection as the rest of the Transact-SQL used by the application. Using a single connection means that a messaging transaction doesn’t need to be a distributed transaction, as it would have to be if the messaging system were external to the database.

Enhanced Security

Because Service Broker messages are handled internally by the database, the access permissions of the message sender can be easily checked against database objects. If the message system were an external process, a separate database connection would be required for each user who is sending messages. Having the same identity for the database and the messaging system makes security easier to set up correctly.

Transmission Queue Visibility Across Databases

Because Service Broker runs in the context of the database instance, it can maintain an aggregate view of all messages that are ready to be transmitted from all databases in the instance. This capability enables each database to maintain its own transmission queues for backup and administration while still maintaining fairness in resource usage across all the databases in the instance, something that would be very difficult, if not impossible, for an external messaging manager to do.

Conclusion

The unique features of Service Broker and its deep database integration make it an ideal platform for building a new class of loosely coupled services for database applications. Service Broker not only brings asynchronous, queued messaging to database applications but significantly expands the state of the art for reliable messaging.

Source: An Introduction to SQL Server Service Broker

List of Active Directory Domain and Forest Functional Levels and Supported Features

Server 2008 R2: Active Directory Functional Levels

MJP | Oct 06, 2009 | 8 comments

Windows Server 2008 R2 was released in August, and it introduced new functional levels for Active Directory. This article takes a look back at the different functional levels of the past and what is new in the latest release of the server operating system for Active Directory (yes, a recycle bin for AD objects!).

Functional levels were first introduced when Active Directory made its appearance in Windows 2000 Server. They allowed you to run different versions of domain controllers in your environment, and when all the domain controllers were brought up to a certain version of Windows, you could raise the functional levels to gain the added features of that operating system version. Now that Windows 2008 R2 is released, it is unlikely that you will mass deploy this new operating system to your entire forest or domain. Instead, you’ll deploy a single domain controller and kick the tires, so to speak. The time will eventually come when you’ve upgraded every domain controller to R2, and at that point you can raise the functional level to 2008 R2 to take advantage of the new features.

Functional levels can be raised in domains or, as of Windows 2003 Server, in the forest, providing different features in each. They are differentiated by labeling them Domain Functional Level and Forest Functional Level.

What’s new in 2008 R2

Domain Functional Level

There are two features added when raising the domain functional level to 2008 R2. They are Authentication Mechanism Assurance and Automatic SPN Management.

Authentication mechanism assurance is meant for domains that utilize federation services (ADFS) or certificate-based authentication methods, such as smart card or token-based authentication. This mechanism adds information to the user’s kerberos token on the type of authentication used. This allows administrators to modify group membership based on how the user authenticates. For example, a user can have access to different resources if they log in with a certificate versus when they log in with just their username and password.

Automatic SPN management provides a method for managing service accounts for applications such as Exchange, SQL and IIS. In the past, regular domain accounts were used for these purposes, adding management headaches in terms of password management and service principle names (SPNs). This new feature provides the following benefits:

• A class of domain accounts can be used to manage and maintain services on local computers.
• Passwords for these accounts will be reset automatically.
• Do not have to complete complex SPN management tasks to use managed service accounts.
• Administrative tasks for managed service accounts can be delegated to non-administrators.

Forest Functional Level

There is one new feature in raising the forest functional level to Server 2008 R2, and it is long overdue. It is the Active Directory recycle bin. In the days of old, when an IT administrator or help desk operator accidentally deleted an OU filled with user or computer objects (this has happened more times than you would think), there would be a scramble to perform a restore. The delete replicates to all domain controllers, so an authoritative restore in Active Directory restore mode from a good backup using NTDSutil would be in order. With 2008 R2 forest functional level, a powershell cmd-let will undo this instantly.

Note that this feature is not enabled automatically when raising forest functional level. Additionally, you must run the following command in the Active Directory Module for Powershell.

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory

Service,CN=Windows NT,CN=Services,CN=Configuration, DC=mydomain,DC=com’

–Scope ForestOrConfigurationSet –Target ‘mydomain.com’

Functional levels of previous version

The following are the previous functional levels and what features they added, as documented in Technet.

---

Domain Functional Levels:

Windows 2000 Native:

• Universal groups are enabled for both distribution groups and security groups.
• Group nesting.
• Group conversion is enabled, which makes conversion between security groups and distribution groups possible.
• Security identifier (SID) history.

Windows Server 2003

• The availability of the domain management tool, Netdom.exe, to prepare for domain controller rename.
• Update of the logon time stamp. The lastLogonTimestamp attribute will be updated with the last logon time of the user or computer. This attribute is replicated within the domain.
• The ability to set the userPassword attribute as the effective password on inetOrgPerson and user objects.
• The ability to redirect Users and Computers containers. By default, two well-known containers are provided for housing computer and user/group accounts: namely, cn=Computers, and cn=Users,. This feature makes possible the definition of a new well-known location for these accounts.
• Makes it possible for Authorization Manager to store its authorization policies in Active Directory Domain Services (AD DS).
• Includes constrained delegation so that applications can take advantage of the secure delegation of user credentials by means of the Kerberos authentication protocol. Delegation can be configured to be allowed only to specific destination services.
• Supports selective authentication, through which it is possible to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest.

Windows Server 2008

• Distributed File System (DFS) Replication support for SYSVOL, which provides more robust and detailed replication of SYSVOL contents.
• Advanced Encryption Services (AES 128 and 256) support for the Kerberos authentication protocol.
• Last Interactive Logon Information, which displays the time of the last successful interactive logon for a user, from what workstation, and the number of failed logon attempts since the last logon.
• Fine-grained password policies (FGPP), which make it possible for password and account lockout policies to be specified for users and global security groups in a domain.

Forest Functional Levels:

Windows 2000:

There were no forest functional levels, just domain.

Windows Server 2003:

• Forest trust.
• Domain rename.
• Linked-value replication (changes in group membership store and replicate values for individual members instead of replicating the entire membership as a single unit). This change results in lower network bandwidth and processor usage during replication and eliminates the possibility of lost updates when different members are added or removed concurrently at different domain controllers.
• The ability to deploy a read-only domain controller (RODC) that runs Windows Server 2008.
• Improved Knowledge Consistency Checker (KCC) algorithms and scalability. The Intersite Topology Generator (ISTG) uses improved algorithms that scale to support forests with a greater number of sites than can be supported at the Windows 2000 forest functional level. The improved ISTG election algorithm is a less intrusive mechanism for choosing the ISTG at the Windows 2000 forest functional level.
• An improved ISTG algorithm (better scaling of the algorithm that the ISTG uses to connect all sites in the forest).
• The ability to create instances of the dynamic auxiliary class called dynamicObject in a domain directory partition.
• The ability to convert an inetOrgPerson object instance into a User object instance, and the reverse.
• The ability to create instances of the new group types, called application basic groups and Lightweight Directory Access Protocol (LDAP) query groups, to support role-based authorization.
• Deactivation and redefinition of attributes and classes in the schema.

Windows Server 2008:

No forest functional level changes occurred from Windows 2003 to Windows 2008.

 

 

Source: Server 2008 R2: Active Directory Functional Levels : Praetorian Prefect

Windows Active Directory: Understanding AD DS Functional Levels

Applies To: Windows Server 2008, Windows Server 2008 R2

Functional levels determine the available Active Directory Domain Services (AD DS) domain or forest capabilities. They also determine which Windows Server operating systems you can run on domain controllers in the domain or forest. However, functional levels do not affect which operating systems you can run on workstations and member servers that are joined to the domain or forest.

When you deploy AD DS, set the domain and forest functional levels to the highest value that your environment can support. This way, you can use as many AD DS features as possible. For example, if you are sure that you will never add domain controllers that run Windows Server 2003 to the domain or forest, select the Windows Server 2008 functional level during the deployment process. However, if you might retain or add domain controllers that run Windows Server 2003, select the Windows Server 2003 functional level.

When you deploy a new forest, you are prompted to set the forest functional level and then set the domain functional level. You cannot set the domain functional level to a value that is lower than the forest functional level. For example, if you set the forest functional level to Windows Server 2008, you can set the domain functional level only to Windows Server 2008. The Windows 2000 native and Windows Server 2003 domain functional level values are not available on the Set domain functional level page of the Active Directory Domain Services Installation Wizard. In addition, all domains that you subsequently add to that forest have the Windows Server 2008 domain functional level by default.

You can set the domain functional level to a value that is higher than the forest functional level. For example, if the forest functional level is Windows Server 2003, you can set the domain functional level to Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.

The following sections describe the features that are available at the different functional levels.

Features that are available at domain functional levels

The following table shows the features that are available at each domain functional level.

Domain functional level	Available features	Supported domain controller operating systems
Windows 2000 native	All of the default AD DS features and the following directory features are available: · Universal groups for both distribution and security groups. · Group nesting · Group conversion, which allows conversion between security and distribution groups · Security identifier (SID) history Note In Windows Server 2008 R2, the Personal Virtual Desktop feature was introduced. It requires the Windows 2000 native domain functional level.	· Windows 2000 · Windows Server 2003 · Windows Server 2008 · Windows Server 2008 R2
Windows Server 2003	All the default AD DS features, all the features that are available at the Windows 2000 native domain functional level, and the following features are available: · The domain management tool, Netdom.exe, which makes it possible for you to rename domain controllers · Logon time stamp updates The lastLogonTimestamp attribute is updated with the last logon time of the user or computer. This attribute is replicated within the domain. · The ability to set the userPassword attribute as the effective password on inetOrgPerson and user objects · The ability to redirect Users and Computers containers By default, two well-known containers are provided for housing computer and user accounts, namely, cn=Computers,<domain root> and cn=Users,<domain root>. This feature allows the definition of a new, well-known location for these accounts. · The ability for Authorization Manager to store its authorization policies in AD DS · Constrained delegation Constrained delegation makes it possible for applications to take advantage of the secure delegation of user credentials by means of Kerberos-based authentication. You can restrict delegation to specific destination services only. · Selective authentication Selective authentication makes it is possible for you to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest.	· Windows Server 2003 · Windows Server 2008 · Windows Server 2008 R2
Windows Server 2008	All of the default AD DS features, all of the features from the Windows Server 2003 domain functional level, and the following features are available: · Distributed File System (DFS) replication support for the Windows Server 2003 System Volume (SYSVOL) DFS replication support provides more robust and detailed replication of SYSVOL contents. · Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for access-based enumeration and increased scalability. Domain-based namespaces in Windows Server 2008 mode also require the forest to use the Windows Server 2003 forest functional level. For more information, see Choose a Namespace Type (http://go.microsoft.com/fwlink/?LinkId=180400). · Advanced Encryption Standard (AES 128 and AES 256) support for the Kerberos protocol · Last Interactive Logon Information Last Interactive Logon Information displays the following information: · The total number of failed logon attempts at a domain-joined Windows Server 2008 server or a Windows Vista workstation · The total number of failed logon attempts after a successful logon to a Windows Server 2008 server or a Windows Vista workstation · The time of the last failed logon attempt at a Windows Server 2008 or a Windows Vista workstation · The time of the last successful logon attempt at a Windows Server 2008 server or a Windows Vista workstation For more information, see Active Directory Domain Services: Last Interactive Logon (http://go.microsoft.com/fwlink/?LinkId=180387). · Fine-grained password policies Fine-grained password policies make it possible for you to specify password and account lockout policies for users and global security groups in a domain. For more information, see Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy Configuration (http://go.microsoft.com/fwlink/?LinkID=91477). · Personal Virtual Desktops To use the added functionality provided by the Personal Virtual Desktop tab in the User Account Properties dialog box in Active Directory Users and Computers, your AD DS schema must be extended for Windows Server 2008 R2 (schema object version = 47). For more information, see Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=183552).	· Windows Server 2008 · Windows Server 2008 R2
Windows Server 2008 R2	All default Active Directory features, all features from the Windows Server 2008 domain functional level, plus the following features: · Authentication mechanism assurance, which packages information about the type of logon method (smart card or user name/password) that is used to authenticate domain users inside each user’s Kerberos token. When this feature is enabled in a network environment that has deployed a federated identity management infrastructure, such as Active Directory Federation Services (AD FS), the information in the token can then be extracted whenever a user attempts to access any claims-aware application that has been developed to determine authorization based on a user’s logon method. · Automatic SPN management for services running on a particular computer under the context of a Managed Service Account when the name or DNS host name of the machine account changes. For more information about Managed Service Accounts, see Service Accounts Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=180401).	· Windows Server 2008 R2

Features that are available at forest functional levels

The following table shows the features that are available at each forest functional level.

Forest functional level	Available features	Supported domain controllers
Windows 2000 native	All of the default AD DS features are available.	· Windows Server 2008 R2 · Windows Server 2008 · Windows Server 2003 · Windows 2000
Windows Server 2003	All of the default AD DS features, and the following features, are available: · Forest trust · Domain rename · Linked-value replication Linked-value replication makes it possible for you to change group membership to store and replicate values for individual members instead of replicating the entire membership as a single unit. Storing and replicating the values of individual members uses less network bandwidth and fewer processor cycles during replication, and prevents you from losing updates when you add or remove multiple members concurrently at different domain controllers. · The ability to deploy a read-only domain controller (RODC) · Improved Knowledge Consistency Checker (KCC) algorithms and scalability The intersite topology generator (ISTG) uses improved algorithms that scale to support forests with a greater number of sites than AD DS can support at the Windows 2000 forest functional level. The improved ISTG election algorithm is a less-intrusive mechanism for choosing the ISTG at the Windows 2000 forest functional level. · The ability to create instances of the dynamic auxiliary class named dynamicObject in a domain directory partition · The ability to convert an inetOrgPerson object instance into a User object instance, and to complete the conversion in the opposite direction · The ability to create instances of new group types to support role-based authorization. These types are called application basic groups and LDAP query groups. · Deactivation and redefinition of attributes and classes in the schema. The following attributes can be reused: ldapDisplayName, schemaIdGuid, OID, and mapiID. · Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for access-based enumeration and increased scalability. For more information, see Choose a Namespace Type (http://go.microsoft.com/fwlink/?LinkId=180400).	· Windows Server 2003 · Windows Server 2008 · Windows Server 2008 R2
Windows Server 2008	All of the features that are available at the Windows Server 2003 forest functional level, but no additional features are available. All domains that are subsequently added to the forest, however, operate at the Windows Server 2008 domain functional level by default.	· Windows Server 2008 · Windows Server 2008 R2
Windows Server 2008 R2	All of the features that are available at the Windows Server 2003 forest functional level, plus the following features: · Active Directory Recycle Bin, which provides the ability to restore deleted objects in their entirety while AD DS is running. All domains that are subsequently added to the forest will operate at the Windows Server 2008 R2 domain functional level by default. If you plan to include only domain controllers that run Windows Server 2008 R2 in the entire forest, you might choose this forest functional level for administrative convenience. If you do, you will never have to raise the domain functional level for each domain that you create in the forest.	· Windows Server 2008 R2

Guidelines for raising domain and forest functional levels

The following guidelines apply to raising the domain or forest functional levels:

· You must be a member of the Domain Admins group to raise the domain functional level.

· You must be a member of the Enterprise Admins group to raise the forest functional level.

· You can raise the domain functional level on the primary domain controller (PDC) emulator operations master only. The AD DS administrative tools that you use to raise the domain functional level (the Active Directory Domains and Trusts snap-in and the Active Directory Users and Computers snap-in) automatically target the PDC emulator when you raise the domain functional level.

· You can raise the forest functional level on the schema operations master only. Active Directory Domains and Trusts automatically targets the schema operations master when you raise the forest functional level.

· You can raise the functional level of a domain only if all domain controllers in the domain run the version or versions of Windows that the new functional level supports.

· You can raise the functional level of a forest only if all domain controllers in the forest run the version or versions of Windows Server operating system that the new functional level supports.

· You cannot set the domain functional level to a value that is lower than the forest functional level, but you can set it to a value that is equal to or higher than the forest functional level.

· With versions of Windows Server that are earlier than Windows Server 2008 R2, you cannot roll back or lower a functional level under any circumstances. If you have to revert to a lower functional level with a version of Windows Server that is earlier than Windows Server 2008 R2, you must rebuild the domain or forest or restore it from a backup copy.

· After you set the domain functional level to a certain value in Windows Server 2008 R2, you cannot roll back or lower the domain functional level, with one exception: when you raise the domain functional level to Windows Server 2008 R2 and if the forest functional level is Windows Server 2008 or lower, you have the option of rolling the domain functional level back to Windows Server 2008. You can lower the domain functional level only from Windows Server 2008 R2 to Windows Server 2008. If the domain functional level is set to Windows Server 2008 R2, it cannot be rolled back, for example, to Windows Server 2003.

· After you set the forest functional level to a certain value in Windows Server 2008 R2, you cannot roll back or lower the forest functional level, with one exception: when you raise the forest functional level to Windows Server 2008 R2 and if the Active Directory Recycle Bin is not enabled, you have the option of rolling the forest functional level back to Windows Server 2008. For more information about the Active Directory Recycle Bin, see What’s New in AD DS: Active Directory Recycle Bin (http://go.microsoft.com/fwlink/?LinkId=141392). You can lower the forest functional level only from Windows Server 2008 R2 to Windows Server 2008. If the forest functional level is set to Windows Server 2008 R2, it cannot be rolled back to Windows Server 2003, for example.

 

Source: Understanding AD DS Functional Levels

Windows Domain and Forest Functionality

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Domain and forest functionality

Domain and forest functionality, introduced in Windows Server 2003 Active Directory, provides a way to enable domain- or forest-wide Active Directory features within your network environment. Different levels of domain functionality and forest functionality are available depending on your environment.

If all domain controllers in your domain or forest are running Windows Server 2003 and the functional level is set to Windows Server 2003, all domain- and forest-wide features are available. When Windows NT 4.0 or Windows 2000 domain controllers are included in your domain or forest with domain controllers running Windows Server 2003, Active Directory features are limited. For more information about how to enable domain- or forest-wide features, see Raising domain and forest functional levels.

The concept of enabling additional functionality in Active Directory exists in Windows 2000 with mixed and native modes. Mixed-mode domains can contain Windows NT 4.0 backup domain controllers and cannot use Universal security groups, group nesting, and security ID (SID) history capabilities. When the domain is set to native mode, Universal security groups, group nesting, and SID history capabilities are available. Domain controllers running Windows 2000 Server are not aware of domain and forest functionality.

Domain functionality

Domain functionality enables features that will affect the entire domain and that domain only. Four domain functional levels are available: Windows 2000 mixed (default), Windows 2000 native, Windows Server 2003 interim, and Windows Server 2003. By default, domains operate at the Windows 2000 mixed functional level.

The following table lists the domain functional levels and their corresponding supported domain controllers.

Domain functional level	Domain controllers supported
Windows 2000 mixed (default)	Windows NT 4.0 Windows 2000 Windows Server 2003 family
Windows 2000 native	Windows 2000 Windows Server 2003 family
Windows Server 2003 interim	Windows NT 4.0 Windows Server 2003 family
Windows Server 2003	Windows Server 2003 family

Once the domain functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the domain. For example, if you raise the domain functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to that domain.

The following table describes the domain-wide features that are enabled for three of the domain functional levels. For information about the Windows Server 2003 interim functional level, see Upgrading from a Windows NT domain.

Domain feature	Windows 2000 mixed	Windows 2000 native	Windows Server 2003
Domain controller rename tool For more information, see Renaming domain controllers.	Disabled	Disabled	Enabled
Different location option for user and computer accounts For more information about how to redirect the default location for user and computer accounts, see Redirect the Users and Computers Containers.	Disabled	Disabled	Enabled
Update logon timestamp For more information about the lastLogonTimestamp attribute, see User and computer accounts.	Disabled	Disabled	Enabled
User password on InetOrgPerson object For more information about InetOrgPerson objects, see User and computer accounts.	Disabled	Disabled	Enabled
Universal Groups For more information, see Group types and Group scope.	Enabled for distribution groups. Disabled for security groups.	Enabled Allows both security and distribution groups.	Enabled Allows both security and distribution groups.
Group Nesting For more information, see Nesting groups.	Enabled for distribution groups. Disabled for security groups, except for domain local security groups that can have global groups as members.	Enabled Allows full group nesting.	Enabled Allows full group nesting.
Converting Groups For more information, see Converting groups.	Disabled No group conversions allowed.	Enabled Allows conversion between security groups and distribution groups.	Enabled Allows conversion between security groups and distribution groups.
SID history	Disabled	Enabled Allows migration of security principals from one domain to another.	Enabled Allows migration of security principals from one domain to another.

Forest functionality

Forest functionality enables features across all the domains within your forest. Three forest functional levels are available: Windows 2000 (default), Windows Server 2003 interim, and Windows Server 2003 . By default, forests operate at the Windows 2000 functional level. You can raise the forest functional level to Windows Server 2003 .

The following table lists the forest functional levels and their corresponding supported domain controllers:

Forest functional level	Domain controllers supported
Windows 2000 (default)	Windows NT 4.0 Windows 2000 Windows Server 2003 family
Windows Server 2003interim	Windows NT 4.0 Windows Server 2003 family
Windows Server 2003	Windows Server 2003 family

Once the forest functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the forest. For example, if you raise the forest functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to the forest.

If you are upgrading your first Windows NT 4.0 domain so that it becomes the first domain in a new Windows Server 2003 forest, you can set the domain functional level to Windows Server 2003 interim. For more information, see Upgrading from a Windows NT domain.

The following table describes the forest-wide features that are enabled for the Windows 2000 and Windows Server 2003 forest functional levels.

Forest feature	Windows 2000	Windows Server 2003
Global catalog replication improvements For more information, see Global catalog replication.	Enabled if both replication partners are running Windows Server 2003. Otherwise, disabled.	Enabled
Defunct schema objects For more information, see Deactivating a class or attribute.	Disabled	Enabled
Forest trusts For more information, see Forest trusts.	Disabled	Enabled
Linked value replication For more information, see How replication works.	Disabled	Enabled
Domain rename For more information, see Renaming domains.	Disabled	Enabled
Improved Active Directory replication algorithms For more information, see Replication overview.	Disabled	Enabled
Dynamic auxiliary classes. For more information, see New features for Active Directory.	Disabled	Enabled
InetOrgPerson objectClass change For more information about InetOrgPerson objects, see User and computer accounts.	Disabled	Enabled

 

Source: Domain and forest functionality

The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state

The documentation for the Dcgpofix.exe tool incorrectly indicates that the Dcgpofix tool will restore security settings in the Default Domain Controller Policy to the same state that they were in immediately after Dcpromo successfully completed. This is not the case.
It is best to use the Dcgpofix tool only in disaster recovery scenarios. The Dcpromo operation modifies the security of the domain in an incremental manner, based on the existing security settings on that server. Therefore, after you run Dcpromo, the final set of security settings in the Default Domain Controller Policy depends on both the Dcpromo operation and the security state of the system that existed before you ran Dcpromo. Before you run Dcpromo, the security state of the system can be modified by a number of mechanisms. For example, when you install some server applications, changes may be made to user rights that are granted to local user accounts, such as the SUPPORT_388945a0 account.

Back to the top

CAUSE

The Dcgpofix tool cannot know what state the security settings were in before yo…

The Dcgpofix tool cannot know what state the security settings were in before you run Dcpromo. Therefore, the Dcgpofix tool cannot return the security settings to precisely the original state. Instead, the Dcgpofix tool recreates the two default Group Policy objects (GPOs) and creates the settings based on the operations that are performed only during Dcpromo.
If you have a new installation of Microsoft Windows Server 2003 and no security changes are made to the operating system before you run Dcpromo, the recreated Default Domain Controller Policy that is created by Dcgpofix will be almost the same as the Default Domain Controller Policy just after you run Dcpromo. However, there will be some differences in the settings in the Default Domain Controller Policy in this case.

Back to the top

RESOLUTION

For general backup and restore of the Default Domain Policy and Default Domain C…

For general backup and restore of the Default Domain Policy and Default Domain Controller Policy, and also for other GPOs, Microsoft recommends that you use the Group Policy Management Console (GPMC) to create regular backups of these GPOs. You can then use GPMC in conjunction with these backups to restore the exact security settings that are contained in these GPOs.
For more information about the GPMC, visit the following Microsoft Web site:

http://www.microsoft.com/windowsserver2003/gpmc/default.mspx (http://www.microsoft.com/windowsserver2003/gpmc/default.mspx)

If you are in a disaster recovery scenario and you do not have any backed up versions of the Default Domain Policy or the Default Domain Controller Policy, you may consider using the Dcgpofix tool. If you use the Dcgpofix tool, Microsoft recommends that as soon as you run it, you review the security settings in these GPOs and manually adjust the security settings to suit your requirements. A fix is not scheduled to be released because Microsoft recommends you use GPMC to back up and restore all GPOs in your environment. The Dcgpofix tool is a disaster-recovery tool that will restore your environment to a functional state only. It is best not to use it as a replacement for a backup strategy using GPMC. It is best to use the Dcgpofix tool only when a GPO back up for the Default Domain Policy and Default Domain Controller Policy does not exist.

Back to the top

MORE INFORMATION

The following table lists differences in security settings in the Default Domain…

The following table lists differences in security settings in the Default Domain Controller Policy after you run the Dcgpofix tool and the settings on a new installation of Windows Server 2003 after you run Dcpromo. Microsoft recommends that you adjust these security settings to match the requirements in your environment after you run the Dcgpofix tool.

Collapse this tableExpand this table

Setting in Default Domain Controller Policy
Value after running DCPromo on cleanly installed Windows Server 2003 system
Value after running DCGPOFIX

Audit Settings

Audit Account Management
Success
No Auditing

Audit Directory Service Access
Success
No Auditing

Audit Policy Change
Success
No Auditing

Audit System Events
Success
No Auditing

User Rights

Create Global Objects
Not defined
SERVICE, Administrators

Deny access to computer from network
SUPPORT_388945a0
(Empty)

Deny logon locally
SUPPORT_388945a0
(Empty)

Impersonate a client after authentication
Not defined
SERVICE, Administrators

Load and unload device drivers
Administrators, Print Operators
Administrators

Log on as a batch job
LOCAL SERVICE, SUPPORT_388945a0
(Empty)

Log on as a service
NETWORK SERVICE
(Empty)

Shut down the system
Administrators, Backup Operators, Server Operators, Print Operators
Account Operators, Administrators, Backup Operators, Server Operators, Print Operators

The following settings will change after you run the Dcgpofix tool:

• AuditAccountManage
• AuditDSAccess
• AuditPolicyChange
• AuditSystemEvents
• SeCreateGlobalPrivilege
• SeImpersonatePrivilege
• SeLoadDriverPrivilege
• SeShutdownPrivilege

Based on configuration options, the following settings may also change the following:

• SeBatchLogonRight (only LOCAL SERVICE, not the SUPPORT_388945a0 account)
• SeServiceLogonRight

Back to the top

---

APPLIES TO

• Microsoft Windows Server 2003, Standard Edition (32-bit x86)
• Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)

 

Source: The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state

Restore AD LDS Instance Data

Step 1: Restore AD LDS Instance Data

Applies To: Windows Server 2008

You should back up Active Directory Lightweight Directory Services (AD LDS) data and log files regularly to ensure the continued availability of data to applications and users in the event of a system failure.

By default, each instance of AD LDS running on an AD LDS server stores its database file, Adamntds.dit, and the associated log files in %program files%\Microsoft ADAM\instance_name\data, where instance_name is the AD LDS instance name. Include these files as part of the regular backup plan of your organization. You back up data for an AD LDS instance by backing up these files.

In the following sections, you back up your AD LDS instance data using the following tools:

· Windows Server Backup

· Dsdbutil.exe

For more information about installing Windows Server Backup, see Installing Windows Server Backup (http://go.microsoft.com/fwlink/?LinkId=96495).

For general information about Windows Server 2008 Windows Server Backup, you can view the Help on your server. To display Help, open Windows Server Backup, and then press F1.

Backing up AD LDS instance data with Windows Server Backup

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

Important

Before you back up the AD LDS folder of an instance, use the Services snap-in to confirm that the instance is started. To start Services, click Start, click Administrative Tools, and then click Services. Because the instance service must be running when the files are backed up, you must use a backup utility (such as Windows Server Backup) that can back up open files.

To back up an AD LDS instance using Windows Server Backup

1. Click Start, point to Administrative Tools, and then click Windows ServerBackup.

2. On the Action menu, click Backup once.

3. In the Backup Once Wizard, on the Backup options page, click Different options, and then click Next.

4. On the Select backup configuration page, click Custom, and then click Next.

5. Select the volume or volumes that contain the AD LDS database and log files, and then click Next.

Note

You can install the AD LDS database and log files on separate volumes.

6. On the Specify destination type page, select Local drives or Remote shared folder, depending on whether you want your backup to be stored locally or remotely.

7. On the Select backup destination page, specify the appropriate drive where you want the backup to be stored.

8. Complete the wizard to begin the backup operation.

Caution

If you backed up data from an NTFS file system volume, we recommend that you restore the data to an NTFS volume of the same version to prevent loss of data.

Backing up AD LDS instance data with Dsdbutil.exe

With the Dsdbutil.exe tool, you can create installation media that corresponds only to the AD LDS instance that you want to back up, as opposed to backing up entire volumes that contain the AD LDS instance.

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

To create AD LDS installation media with Dsdbutil.exe

1. Click Start, right-click Command Prompt, and then click Run as administrator to open an elevated command prompt.

2. Type the following command, and then press ENTER:

Copy

dsdbutil

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

Copy

activate instance <instance_name>

where <instance_name> is the name of the AD LDS instance that you want to create the installation media for.

Example:

Copy

activate instance instance1

At the dsdbutil: prompt, type the following command, and then press ENTER:

Copy

ifm

4. At the ifm: prompt, type the command for the type of installation media that you want to create, and then press ENTER:

Copy

create full <location>

where <location> is the path to the folder where you want the installation media to be created. You can save the installation media to a network shared folder or to any other type of removable media.

Example:

Copy

create full C:\Backup\instance1

5. To exit dsdbutil:

a. At the ifm: prompt, type quit, and then press ENTER.

b. At the dsdbutil: prompt, type quit, and then press ENTER.

Source: Step 1: Back Up AD LDS Instance Data

 

Step 2: Restore AD LDS Instance Data

Applies To: Windows Server 2008

To restore your Active Directory Lightweight Directory Services (AD LDS) instance data, select a procedure that is most appropriate for your AD LDS restore scenario:

· Restore an existing AD LDS instance

· Restore a retired AD LDS instance

· Authoritatively restore an AD LDS instance

· Install an AD LDS replica from media

Restore an existing AD LDS instance

You can restore an existing AD LDS instance to its state at the time when its backup was created. When you restore a database for an existing AD LDS instance, you must stop the AD LDS instance before you run the restore operation. In addition, we recommend that you move (or delete) the existing database and log files from the AD LDS instance before you begin the restore operation.

If you restore an AD LDS backup over a running AD LDS instance, Windows Server Backup leaves the restored files in a pending state, and it does not write the files to disk until the computer reboots. In this situation, any directory changes that are made to the running AD LDS instance after Windows Server Backup is run are lost.

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

To restore an existing AD LDS instance

1. Stop the AD LDS instance that you just created, as follows:

a. Click Start, point to Administrative Tools, and then click Services.

b. In Services, right-click the AD LDS instance, and then click Stop.

Note

If you accidentally start a restore of an AD LDS instance over a currently running AD LDS instance, we recommend that you immediately restart the computer, stop the AD LDS instance, and then perform the restoration again.

2. Click Start, click Administrative Tools, and then click Windows ServerBackup.

3. On the Action menu, click Recover.

4. Follow the steps in the Recovery Wizard to specify the location of the source backup data and identify the specific backup from which you want to recover instance data:

a. In Select recovery type, click Files and folders, and then click Next.

b. In Select items to recover, browse to and select the folder that contains the instance data files. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instance_name\data, where instance_name is the AD LDS instance name.

c. In Specify recovery options, click Original location and Overwrite existing files with recovered files, and then click Next.

5. To complete the restore, click Recover.

6. After the restore is complete, close Windows Server Backup.

7. Start the AD LDS instance as follows:

a. Click Start, point to Administrative Tools, and then click Services.

b. In Services, right-click the AD LDS instance, and then click Start.

Note

You cannot use Windows Server Backup to restore an existing AD LDS instance with a backup that was created with the Dsdbutil.exe tool. To restore your existing AD LDS instance with a backup that was created with Dsdbutil.exe, see Appendix B: Restore an AD LDS Instance with a Backup Taken with Dsdbutil.exe.

Restore a retired AD LDS instance

To restore a retired AD LDS instance (or to move a specific AD LDS instance from one server to another), you must begin the recovery process by creating a new AD LDS instance using the same settings that were specified during the installation of the AD LDS instance that you want to recover or move.

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

To restore a retired AD LDS instance

1. Using the Active Directory Lightweight Directory Services Setup Wizard, create an AD LDS instance, specifying the same settings that you used during your original (uninstalled) AD LDS installation. However, do not create an application directory partition during setup. For more information about creating AD LDS instances, see the Step-by-Step Guide for Getting Started with Active Directory Lightweight Directory Services (http://go.microsoft.com/fwlink/?LinkId=98679).

2. Stop the AD LDS instance that you just created, as follows:

a. Click Start, point to Administrative Tools, and then click Services.

b. In Services, right-click the AD LDS instance, and then click Stop.

Note

If you accidentally start a restore of an AD LDS instance over a currently running AD LDS instance, we recommend that you immediately restart the computer, stop the AD LDS instance, and then perform the restoration again.

3. Click Start, click Administrative Tools, and then click Windows ServerBackup.

4. On the Action menu, click Recover.

5. Follow the steps in the Recovery Wizard to specify the location of the source backup data and identify the specific backup from which you want to recover instance data.

6. In Select recovery type, click Files and folders, and then click Next.

7. In Select items to recover, browse to and select the folder that contains the instance data files. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instance_name\data, where instance_name is the AD LDS instance name.

8. In Specify recovery options, click Original locations and Overwrite existing files with recovered files, and then click Next.

9. To complete the restore, click Recover.

10. After the restore is complete, close Windows Server Backup.

11. Start the AD LDS instance that you just created, as follows:

a. Click Start, click Administrative Tools, and then click Services.

b. In Services, right-click the AD LDS instance, and then click Start.

Important

Backing up an ADAM instance on a computer running Windows Server 2003 and restoring it onto an AD LDS instance on a computer running Windows Server 2008 or Windows Server 2008 R2 is not supported.

Note

You cannot use Windows Server Backup to restore a retired AD LDS instance with a backup that was created with Dsdbutil.exe. To restore your existing AD LDS instance with a backup that was created with Dsdbutil.exe, see Appendix B: Restore an AD LDS Instance with a Backup Taken with Dsdbutil.exe.

Note

If you no longer have access to the retired AD LDS instance that you want to restore, (for example, the administrative account from the server that originally hosted the retired AD LDS instance is gone), you can take ownership and grant selected users permissions to the application, configuration, or schema partitions of this AD LDS instance. For more information, see article 958973 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=149116).

Authoritatively restore an AD LDS instance

If objects in the directory are inadvertently deleted or modified, and if those objects are replicated in a configuration set, you must authoritatively restore those objects so that the correct version of the objects is replicated.

To authoritatively restore directory data, run the dsdbutil tool after you restore the data but before you restart the AD LDS instance. With dsdbutil, you can mark directory objects for authoritative restore. When an object is marked for authoritative restore, its update sequence number is changed so that the number is higher than any other update sequence number in the configuration set. This ensures that any data you restore is properly replicated throughout the configuration set.

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

To authoritatively restore an AD LDS instance

1. If it is running, stop the AD LDS instance for which data will be restored:

a. Click Start, point to Administrative Tools, and then click Services.

b. In Services, right-click the AD LDS instance, and then click Stop.

Note

If you accidentally start a restore of an AD LDS instance over a currently running AD LDS instance, we recommend that you immediately restart the computer, stop the AD LDS instance, and then perform the restoration again.

2. Click Start, click Administrative Tools, and then click Windows ServerBackup.

3. On the Action menu, click Recover.

4. Follow the steps in the Recovery Wizard to specify the location of the source backup data and to identify the specific backup from which you want to recover instance data.

5. In Select recovery type, click Files and folders, and then click Next.

6. In Select items to recover, browse to and select the folder that contains the instance data files. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instance_name\data, where instance_name is the AD LDS instance name.

7. In Specify recovery options, click Original locations and Overwrite existing files with recovered files, and then click Next.

8. To complete the restore, click Recover.

9. After the restore is complete, close Windows Server Backup.

10. Click Start, right-click Command Prompt, and then click Run as administrator.

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

Copy

dsdbutil

12. At the dsdbutil: prompt, type the following command, and then press ENTER:

Copy

activate instance <instance_name>

where <instance_name> represents the service name of the AD LDS instance on which you want to restore data.

13. At the dsdbutil: prompt, type the following command, and then press ENTER:

Copy

authoritative restore

14. At the authoritative restore: prompt, type one of the commands in the following table.

Command	Description
restore object dn	Performs authoritative restore of the directory object whose distinguished name is represented by dn.
restore subtree dn	Performs authoritative restore of the directory subtree whose distinguished name is represented by dn.

15. To view the complete syntax for this command, and for information about the authoritative restore command in dsdbutil, at the authoritative restore: prompt, type:

16. Copy

17. ?

18. To exit dsdbutil:

a. At the authoritative restore: prompt, type quit, and then press ENTER.

b. At the dsdbutil: prompt, type quit, and then press ENTER.

19. Start the AD LDS instance as follows:

a. Click Start, click Administrative Tools, and then click Services.

b. In Services, right-click the AD LDS instance, and then click Start.

Note

You cannot use Windows Server Backup to restore an AD LDS instance with a backup that was created with Dsdbutil.exe. To restore your existing AD LDS instance with a backup that was created with Dsdbutil.exe, see Appendix B: Restore an AD LDS Instance with a Backup Taken with Dsdbutil.exe.

Install an AD LDS replica from media

When you install an AD LDS replica from media, you restore a backup of another AD LDS instance from the same configuration set, rather than performing a simple AD LDS replica installation.

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

Note

If Dsdbutil.exe was used to create the installation media (backup) of your AD LDS instance data, skip Steps 1 through 7 and begin this procedure with Step 8.

To install an AD LDS replica from media

1. Click Start, point to Administrative Tools, and then click Windows ServerBackup.

2. On the Action menu, click Recover.

3. Follow the steps in the Recovery Wizard to specify the location of the source backup data and identify the specific backup from which you want to recover instance data.

4. In Select recovery type, click Files and folders, and then click Next.

5. In Select items to recover, browse to and select the folder that contains the instance data files. By default, AD LDS database and log files are located in %ProgramFiles%\Microsoft ADAM\instance_name\data where instance_name is the AD LDS instance name.

6. In Specify recovery options, click Another location, specify a temporary location for the recovered files, and then click Next.

7. To complete the restore, click Recover.

8. At a command prompt, type the following command, and then press ENTER:

Copy

%windir%\adam\adaminstall /adv

9. Follow the steps in the Active Directory Lightweight Directory Services Setup Wizard:

a. On the Select Options page, click A replica of an existing instance, and then click Next.

b. On the Joining a Configuration Set page, type the host name or Domain Name System (DNS) name of the computer where one of the remaining AD LDS instances of the configuration set is installed. Then, type the Lightweight Directory Access Protocol (LDAP) port number in use by that AD LDS instance, and then click Next.

c. On the Administrative Credentials for the Configuration Set page, click the account that is used as the AD LDS administrator for your first AD LDS instance.

d. On the Copying Application Information page, select From the restored backup files in these folders, specify the correct location of the installation media files in the Restored data folder field, leave the Restored data recovery folder field empty, and then click Next.

e. On the Copy Application Partition page, select the application directory partitions that you want to replicate to the new AD LDS instance.

f. Accept the default values on the remaining Active Directory Lightweight Directory Services Setup Wizard pages by clicking Next on each page, and then click Finish on the Completing the Active Directory Lightweight Directory Services Setup Wizard page.

Important

You can also use this procedure to restore a retired AD LDS replica from media. However, we recommend that you first perform a metadata cleanup of any retired AD LDS replica that you plan to restore from media. For more information about metadata cleanup, see Appendix A: Metadata Cleanup for the Retired AD LDS Instances.

 

Source: Step 2: Restore AD LDS Instance Data