Synchronizing Printers, Sites, and Subnets

Applies To: Windows Server 2003 with SP1

This Solution Guide provides a method for synchronizing printer location information between multiple Active Directory forests. By synchronizing printer location information, any user can use Active Directory to locate the nearest physical printer, regardless of which forest the user or printer has an account in.

This solution guide parallels the planning and design process that is defined in the MIIS 2003 Planning and Design guides. As you work through this solution guide, use the MIIS 2003 Planning and Design guides and record your design decisions in the accompanying worksheets. Tables with pre-populated data have been provided in the Appendix of this solution guide to help with your documentation of the design decisions.

Supplemental documentation and resources

Required documentation

MIIS 2003 Planning and Design collection

Recommended documentation

Understanding how MIIS 2003 works	MIIS 2003 Technical Reference
Creating management agents MIIS Security groups	MIIS 2003 Online Help
Understand provisioning	Simple Provisioning from the MIIS 2003 Scenario Walkthroughs
Planning and creating synchronization rules	MIIS 2003 Online Developer Reference Planning Synchronization Rules chapter from the MIIS Planning and Design collection
Understanding sites and subnets	Windows Server 2003 Help
Understanding AD container behavior	Windows Server 2003 Help

Solution Overview

Problem description

While most smaller enterprises deploy a single Active Directory forest to manage their enterprise networks, more and more medium and large enterprises are having to deploy multiple Active Directory forests for various reasons:

• Mergers and acquisitions

• Divestitures

• Service isolation

• Data isolation

• Pilot deployments

Because multiple forest environments isolate resources between the forests, Active Directory does not provide a mechanism for consistent information views across forests. In the cases of service and data isolation, and pilot deployments, this isolation may be pre-planned and acceptable behavior. However, in the cases of unplanned multiple forests, isolation of certain resources can impede efficient workflow and user operations.

For example, a user from Forest A is working at a remote location and logs on to a laptop to open and print a document. If printer location tracking is enabled, the user can query Active Directory to find the nearest printer when the user tries to add a network printer by using the Add Printer Wizard. However, the user will be able to find only printers in Forest A. To find and connect to a local printer that does not have an account in Forest A, the user must physically locate the nearest printer and connect by using the print server and printer name.

Solution

To enable our user to query Active Directory to find the closest physical printer from any location, all the printer location information will need to be synchronized between all the forests in the enterprise. This synchronized information can be used along with the Active Directory printer location feature to locate any published printer in the enterprise. The printer location feature works by determining the users current subnet location, and matching the location attribute of the subnet with printers that have the same location attribute value. Because the location of the user is determined by their current site and subnet, we will also be interested in synchronizing the site and subnet objects between forests.

Enterprises often store the site and subnet infrastructure for the entire enterprise in one authoritative location, either in Active Directory or a separate database, and update this source location as needed. One solution that many enterprises implement is to develop an additional manual process to update target forests with this information from this one authoritative source. However, this can be costly in terms of administrative overhead, and inefficient as data can quickly become unsynchronized.

Our solution will be to automate the synchronization of this master information using MIIS 2003, where one master source will push its stored printer, site and subnet information out to multiple target forests. Note that this single master solution is the most effective way of demonstrating the concept of this solution. You may find that variations to this solution are necessary for your particular enterprise.

Alternative Solutions

While the "one master to multiple target" method was determined to be the most efficient solution for this Solution Guide, other possible solutions were considered for this problem, including:

• Multiple master sources - In this scenario, multiple forests can be the source for site and subnet information. While this scenario can be supported using MIIS 2003, the administrative overheard of tracking the complexity of changes makes this an inefficient choice. Using this model, each change would involve a validation process to determine the authoritative ownership of that particular object.

• Manual synchronization - In cases where service isolation is required, that is, where the service administration in the source forest isn't trusted by the service administration in the target forest, and therefore unable to create, delete, or modify object in the target forest, a manual synchronization process may be necessary. This would involve creating a business process wherein the Network administration (owners of the site and subnet structure) informs the service administration of the restricted forest of changes, which can then be propagated. There is more administration overhead with this solution, but if isolation is required it is unavoidable.

Designing and planning the Solution

Throughout the design process, you should have print outs of the MIIS 2003 Planning and Design guides and worksheets with you. As design decisions are made, you will need to refer to the guides and record the decisions in the worksheets. These worksheets can then be used for reference when you implement your solution.

Identify the connected data sources

We stated above that this solution will use a single authoritative source for the site and subnet infrastructure information. This solution was chosen for its efficiency and simplicity. Because only one source is considered authoritative, there is not the extra decision processing that is involved with a multi-source solution, and because the information is assumed to come from a secured source, detection of invalid data is not a high priority.

It is recommended that you first sketch out a diagram similar to the one below to help identify which data sources in your environment will be involved in the solution, and to indicate the flow of the data from source to target. These working diagrams can be helpful as you make decisions during the design and planning process.

Because you will be using a single master scenario, first determine which database or directory will be your master source. The following picture describes the general dataflow of the solution, and how MIIS 2003 fits in the process.

1. The infrastructure data is brought into the MIIS staging area from the source database. This may be a separate database, such as SQL, or the data may already be stored in Active Directory.

2. The infrastructure data is either created as new objects, or linked to existing objects in the MIIS database.

3. The infrastructure data is pushed out the staging area of the target forests

4. The infrastructure data is exported to the selected target forests.

Since you need to ensure that the data that is stored in MIIS 2003 is authoritative, you will configure your processes such that the source shown here is the master source. As such, only data originating from the master source will be allowed to update the objects in MIIS (and hence, the remaining target forests). Using the above diagram and the Connected Data Sources worksheet, analyze your environment and identify your master source, and all target forests that are to receive data from the master source.

Identify objects that need to be synchronized

Once the master source and target forests have been determined, you will need to determine which objects need to be synchronized from the master source to the target forest in order to enable the user to locate printers across the enterprise.

The goal for this solution is to be able to locate printqueue objects in Active Directory from anywhere in the enterprise. Printqueue objects reside on subnets, which reside in site containers. When site, subnet, and sitelink information in all forests has been synchronized and is available across the forests, the location of objects in the sites and subnets, such as printqueues, is easy to retrieve anywhere in Active Directory. Note that site, subnet, and sitelink information is not required to publish a printqueue object in Active Directory, but they are necessary for Active Directory printer location to work, therefore you will want to synchronize them.

In addition the basic site and subnet object types, you will also need the container objects for them, along with required child objects. For example, a site object will require a SitesContainer object, and the ServerContainer and NTDSSiteSettings child objects.

Use Table 1 in the Appendix to list the objects that you will need to synchronize for the solution.

Identify object level policies

To begin design on the object level policies, you should first analyze the desired behavior of the system objects during the three basic object actions: Create or add, modify, and delete.

Add scenario

When administrators of the target forests need to create new objects for their forests, they may either create them in their own forests or in the master source.

New object created in the master source:

1. The object is staged to the master source connector space and projected to the metaverse

2. The metaverse object is provisioned to all the target connector spaces and staged as an export

3. The target management agents export the new objects to the target forests and verify the export.

New object created in a target forest:

1. The master source is updated with the new object by the defined update process

2. The object is staged to the master source connector space and projected to the metaverse

3. The metaverse object is provisioned to all the target connector spaces and staged as an export

4. The target management agents export the new objects to the target forests and verify the export.

Modify scenario

Modification for all objects may originate from the master source or from the target forests.

Object modified in the master source:

1. The master source connector space object is updated

2. The updates are flowed to all the target connector spaces and staged as an export

3. The target management agents export the updates to the target forests and verify the export.

Object modified in a target forest:

1. The master source is updated by the defined update process

2. The update is staged to the master source connector space

3. The updates are flowed to all the target connector spaces and staged as an export

4. The target management agents export the updates to the target forests and verify the export.

Deletion scenarios

Object deletions may originate in the master source or from the target forests.

Object deleted in the master source:

1. The deletion is staged to the master source connector space

2. The object is disconnected from the connector spaces, deleted from the metaverse, and staged to all the target connector spaces as an export

3. The target management agents export the deletions to the target forests and verify the export.

Object deleted in a target forest:

1. The master source is updated by the defined update process

2. The deletion is staged to the master source connector space

3. The object is disconnected from the connector spaces, deleted from the metaverse, and staged to all the target connector spaces as an export

4. The target management agents export the deletions to the target forests and verify the export.

Use the data summarized in Table 2 of the Appendix to begin filling out the object level policies. Note that these operations will also be detailed during the design of the synchronization rules later in this guide.

Inbound attributes

Next, you need to determine which attributes you will need to synchronize for each selected object. Remember that any object in Active Directory must have a minimum set of attributes that is defined by the Active Directory schema. However, you will not need to synchronize all of these attributes, only those required to support printer location tracking. Table 3 in the Appendix lists the recommended source attributes for each object from the Real-world Identity Objects worksheet.

Note that five attributes for the printqueue object have been marked as required. These are the only attributes required to create the printqueue object in Active Directory. The other attributes, however, describe the location and functionality of the printqueue and are necessary to locate and view the printqueue object properties.

Similarly, all subnet and siteLink objects require attributes that refer to other objects. For example, subnet objects require the siteObject attribute that refers to the site that the subnet is associated with, and siteLink objects require the siteList attribute that lists all the sites connected over that sitelink. Use the data in Table 3 to complete the Included Attributes worksheet.

Outbound attributes

Because the goal of the solution requires synchronizing the sites and subnet infrastructure across multiple forests, the outbound attribute set should be identical to the inbound attribute set that was just determined. Use Table 3 in the Appendix to complete the Outbound Attribute Flow worksheet.

Planning the metaverse

Metaverse object design

To synchronize objects between the master source and the target forests, each object must be stored in the MIIS 2003 metaverse as a metaverse object type. The MIIS 2003 metaverse is installed with a default schema of objects and attributes. Because the selected objects from Table 1 don't have directly corresponding metaverse object types, you will need to create new metaverse object types.

In our examples, we have used a naming scheme that prefixes "Master" to each new metaverse object name, for example, MasterSubnet, to help clarify the metaverse object from the data source objects.

Use the data in Table 4 in the Appendix to complete the Metaverse Object Design worksheet.

Inbound attribute flow

Because the dataflow in our solution runs only one way, from the master source to the target forests, the inbound attribute values will come only from the master source. If you are validating the data as it is updated in the master source, you will need determine whether or not validate the data again before synchronizing the changes with MIIS 2003.

For consistency and convenience, a naming scheme that allows the inbound, outbound, and metaverse attributes to be named the same is recommended. Unlike the naming scheme for the metaverse objects, there is no advantage in differentiating the metaverse attribute from the inbound and outbound attributes.

All source objects should link to the "master" metaverse object with same name, and because of the direct one-on-one nature of the dataflow, no manual precedence is necessary. The master source should have precedence of all attributes. Use Table 3 in the Appendix to complete the Inbound Attribute Flow worksheet.

Metaverse attribute design

When you create the new metaverse objects, you will also need to create the attributes associated with them. Some attributes, such as location or cn, exist in the metaverse schema by default. The other attributes need to be created in accordance with the naming decisions previously made, that is, naming the metaverse attribute the same as the inbound and outbound attributes.

Use the data in Table 6 in the Appendix to complete the Metaverse Attribute Design worksheet. This is a list of all attributes needed to create the new metaverse objects from the Metaverse Object Design worksheet.

Planning synchronization rules

Connector Filter Rules

Connector filter rules are used to determine if an object should be processed any further after it has been staged to the connector space. Because this solution is based on duplicating objects and attributes from the master source to the target forests, there is a direct one-to-one flow from the master source, through the metaverse, and out to the target forests. Every object that you select in the master source will be synchronized. Therefore, no connector filter rules are necessary, because there are no unwanted objects being imported to begin with.

Join rules

Join rules are used to connect incoming source objects with existing metaverse objects. Because all metaverse objects are created from master source objects, any new incoming source object will always be projected. However, you may run occasional full imports from the master source to keep the connector space up to date. In this case, incoming source objects will need to be joined to their respective metaverse objects. Use the data in Table 7 in the Appendix to complete the Join Rules worksheet.

Projection rules

Projection rules are analyzed to determine if a new metaverse object should be created. For our solution, the master source is the authoritative source for all the relevant objects and attributes in the metaverse (that is, the ones involved directly with printer synchronization). Therefore, projection rules should be configured for all inbound object types on the master source management agent. Use the data in Table 8 in the Appendix to complete the Projection Rules worksheet.

Import attribute flow rules

As determined earlier, due to the one way dataflow of our solution, import attribute flow should only be configured for the master source management agent.

With one exception, all attribute mapping types should be direct mappings, and use the default precedence, where the master source is authoritative. The exception will be the DNComponent attribute for the MasterSite metaverse objects, which will need to be created with a rule extension. Use the data in Table 9 in the Appendix to complete the Import Attribute Flow rules worksheet.

Object deletion rules

This rule determines when the metaverse object should be subject to deletion. Because there is a one-way dataflow in this solution, metaverse object deletion for all Master* metaverse objects should be determined by the object link to the master source. When this link is disconnected, the metaverse object should be deleted. If the link from another target forest management agent is disconnected, it should be ignored, and the disconnector re-connected on the next synchronization pass.

Provisioning rules

Provisioning rules need to be configured to create, modify, or delete a matching target forest object based on changes to the master source object. For example, if a printer is added to the master source, a corresponding printqueue object would be added to the target forests. When the description of a site changes on the master source, the description of the corresponding target site would also change.

By default, the following object types reside in the CN=Sites, CN=Configuration container of each target forest:

• Site

• Subnet

• SiteLink

The provisioning rules for these objects will affect the corresponding objects in the target Configuration containers.

As stated earlier, when a site object is provisioned, the provisioning code must also create a Servers container and NTDSSiteSettings container under the new site object.

Printqueue objects, however, can reside in any accessible container that you specify in different target forests. Therefore, provisioning rules for printqueue objects must be configured to create, modify, or delete the matching target printqueue object in the specified containers in each target forest. Configuring these user specified containers is discussed later in this guide.

Since provisioning rules are called whenever a change occurs on a metaverse object, we can also use the provisioning rules to handle the special case of deleting a site object. Site objects are deleted using the following logic:

Detect if site has child objects

If child objects exist

Cycle through and deprovision child objects

Run full sync from master source to deprovision tarage site.

See Tables 11 and 12 in the Appendix for provisioning scenarios.

Deprovisioning rules

Deprovisioning rules determine what happens to a connector space object after it has been disconnected from the metaverse object. Because all deletions will come from the master source, the target management agents should configure deprovisioning to stage a deletion for export when objects are disconnected.

See Table 13 in the Appendix for deprovisioning scenarios.

Export Attribute flow rules

Again, due to the direct one-to-one nature of the dataflow, the export attribute flow rules are simply the import attribute flow rules in reverse, with these exceptions:

• The flags attribute for MasterPrintqueue objects. If the Windows printer pruning service is activated in the target forest, printers are subject to being deleted under certain circumstances. By setting the correct value on the flags attribute, the printers can be configured such they will not be deleted by the pruning service.

• The DNComponent attribute of MasterSite objects. This attribute is used only by the metaverse.

• The SiteList attribute is multi-valued and requires a rules extension.

Use the data in Table 14 in the Appendix to fill out the Export Attribute Flow rules worksheet, and to see sample logic for flowing the SiteList attribute.

Planning your System Configuration

Management agent configuration

As you plan for your management agent configuration, keep in mind that most of the decisions and information that you need have already been included in the tables in the Appendix and the worksheets up to this point.

Some additional items to consider when configuring management agents:

• Remember that except for the printqueue objects, all the synchronized objects, in both the master and target forests, reside in the CN=Sites, CN=Configuration container. The partition with this container, and all sub-containers, must be selected during configuration of the management agent.

• For printers, remember that they can reside in a user specified organizational unit anywhere in the forest. The partition with this user specified container must be selected on the target management agents. All sub-containers should be included as well.

• You will need to determine the rights needed by the management agents to access containers on the master and target forests. Aside from the default rights for Active Directory management agents, (see Tables 15 and 16 in the Appendix) you will need to determine any unique rights required by the master data source, your enterprise, or by each target forest administrator.

Run profiles are a set of guidelines and parameters that determine the particular steps and functions of a management agent. Remember that each management agent can have multiple run profiles. Review your dataflow diagrams and analyze the run profiles that your management agents will need. Some suggestions are:

• Master

  • Full Import and Full Synchronization -To initially import and provision the required objects. Also used for a periodic refresh of the data across the forests and the metaverse, and to reevaluate all rules. A full import and synchronization is the last required step to remove site objects with servers. (See Provisioning rules above).

  • Delta Synchronization – Applies rules to any connector space objects with pending changes, and will evaluate all disconnected objects

  • Delta import and Delta Synchronization – Import objects with changes and synchronizes those objects with metaverse.

  • Full Import (stage only) – Imports all selected objects to the connector space only. Optionally, you can save the object data to a file for review.

  • Full Synchronization – Reevaluates all rules and all objects

• Target

  • Full Import (stage only) – Imports the Active Directory infrastructure to the connector space. Optionally, you can save the object data to a file for review.

  • Export – exports any objects with pending changes

  • Delta import (stage only) - Use to verify that an export was successful.

General planning considerations

The information in the following worksheets from the Planning and Design guides is not specific to this solution, but is a general planning consideration for every MIIS 2003 deployment. Using the Planning Your System Configuration for MIIS 2003 guide for reference, review these tasks for your environment and make the decisions accordingly.

Roles, Responsibilities, and rights assignments

Identify the team members that will require access to the MIIS 2003 files, and identify the minimum permissions necessary to perform their tasks. Use the default MIIS 2003 security groups to control access to the data files and folders, and to Identity Manager. Use worksheet 21 to list and identify all possible rights abuses.

Security configuration

Use this worksheet to analyze and list security requirements for the MIIS 2003 server, the SQL 2000 server where the MIIS 2003 database resides, and all connected data sources.

Server configuration

Identify the server names, the database location, and any warm standby servers.

Data handling

Use the Preview feature in Identity Manager to preview and analyze how the data is processed by the rules you have configured.

Retrieving information with WMI

Use WMI to retrieve results and statistics, set passwords, or automate tasks for MIIS 2003. See the MIIS 2003 Developers Reference for more information.

System backup

Develop a backup plan for MIIS 2003 security keys, database files, log files, and management agent code.

Implementing the solution

Assumptions

This solution guide makes the following assumptions about your Active Directory environment. If your environment does not match these, you will need to take steps to modify your Active Directory environment before proceeding further with the deployment of the solution.

• The DNS, WINS, and IP infrastructure across the enterprise is configured and stable.

• There are no firewalls between the master and target forests

• There is a high level of cooperation and trust between the master and target forest administrators.

• Consistent connectivity between master and target forests. This will help to ensure that accurate synchronization occurs and that current information is available.

• The site and subnet infrastructure should exist on the target forests per the following standard Active Directory example. This infrastructure can be viewed by using Active Directory Sites and Services.

CN=Sites, CN=Configuration, DC=YourDomain, DC=Com 

CN= < site 1 >

CN=NTDS Site Settings

CN= < site 2 >

CN=NTDS Site Settings

CN= < site n >

CN=NTDS Site Settings

CN=Inter-Site Transport

CN=IP

Cn = < siteLink 1 .. n >

Cn = < siteLinkBridge 1 .. n >

CN=SMTP

Cn = < siteLink 1 .. n >

Cn = < siteLinkBridge 1 .. n >

CN=Subnets

• All site and subnet information is published in master source per the above example.

Pre-configuration tasks

• Each target forest must have an organizational unit (OU) where the printqueue objects will be created and synchronized. This OU can be created anywhere in the tree.

• The location attribute of the master source printer and of its related subnet object must match.

Install MIIS if needed

For more information, see the MIIS 2003 Installation guide that is included on the MIIS 2003 CD.

Modify the MIIS Schema

New object types need to be created in the metaverse to correspond to the data source object types being synchronized. Use the data in Tables 4 and 6 in the Appendix to create new metaverse objects using the Metaverse Designer. For procedures to create new metaverse objects using Metaverse Designer, see the MIIS 2003 online help.

Create provisioning and deprovisioning code, identify dll's

Create the management agents

Using the data worksheets as reference, use the Management Agent Designer in Identity Manager to create each management agent, configure the synchronization rules, and create and configure the run profiles.

Create security group membership

Based on the roles and responsibilities, configure your security and security group membership appropriately.

Run the management agents in preview mode

It is strongly recommended to run the management agents first in preview mode to catch any errors before committing any synchronization changes.

Run the management agents in production

Run the management agents in the following order:

• Target forests - Run a Full Import (Stage Only) to import the Active Directory infrastructure to the connector space.

• Master source - Run a Full import and Full sync to populate the metaverse and the target connector spaces

• Target forests - Run an Export to push pending changes out to the target forests

• Target forests - Run a Delta import to confirm the previous exports

• To synchronize changes on a regular basis, run the management agents in the following sequence:

• Master source - Delta import and Delta synchronization

• Target forest - Export and Delta import for confirmation

Appendix

Table 1 - Real World Identity Objects

Object type	Project Y/N	Join Y/N	Provision Y/N
Site	Y	N	Y
SiteLink	Y	N	Y
Subnet	Y	N	Y
printQueue	Y	N	Y
Server	N	N	N
SubnetContainer	N	N	N
ServerContainer	N	N	N
SitesContainer	N	N	N
NTDSSiteSettings	Y	Y	Y
LicenseSiteSettings	Y	Y	Y
InterSiteTRansportContainer	N	N	N
InterSiteTRansport	N	N	N
OU	N	N	N
Container	N	N	N
DomainDNS	N	N	N
Configuration	N	N	N
Computer	N	N	N

Table 2 - Object-level policies

Object type	Added in master	Modified in master	Deleted in master
Site	Create in all targets	Rename of non-leaf object not allowed.	Delete from target. If there are child servers, target forest administrator needs to manually remove servers before sites can be removed.
SiteLink	Create in all targets	Modify in all targets	Delete from target
Subnet	Create in all targets	Modify in all targets	Delete from target
printQueue	Create in all targets	Modify in all targets	Delete from target

Table 3 - Inbound (and outbound) attributes

Object	Attributes	Required to create object in AD	Mulit-valued Y/N	Outbound	Validation Y/n	Overwritten with Null Y/N
printqueue	Cn name UNCName versionNumber Location serverName portName driverName priority printBinNames printMaxResolutionSupported printOrientationsSupported printCollate printColor printShareName printSpooling printKeepPrintedJobs driverVersion printMaxXExtent printMaxYExtent printMinXExtent printMinYExtent printStaplingSupported printMemory printMediaReady printMediaSupported printerName url shortServerName PrintDuplexSupported Flags printStartTime printEndTime printLanguage printRate printRateUnit printNumberUp printPagesPerMinute	N N Y Y Y Y N N N N N N N N N N N N N N N N N N N N Y N Y N N N N N N N N N	N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N	Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y	N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N	N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
Site	Cn description	N N	N N	Y Y	N N	N N
Subnet	Cn description SiteObject	N N Y	N N N	Y Y Y	N N N	N N N
SiteLink	Cn Description siteList cost replInterval	N N Y Y Y	N N Y N N	Y Y Y Y Y	N N N N N	N N N N N
NTDSSiteSettings	Cn Description	Y N	N N	Y Y	N N	N N

Table 4 - Metaverse object design

Metaverse object name	Joined Y/N	Metaverse Attributes
MasterPrintQueue	Y	Same as source object attribute set
MasterSite	Y	Same as source object attribute set
MasterSubnet	Y	Same as source object attribute set
MasterSiteLink	Y	Same as source object attribute set
MasterNTDSSiteSettings	Y	Same as source object attribute set

Table 5 Metadirectory Object Policies

MV Object	Rules	Details
MasterPrintqueue	Connector Filter	NA
	Join	NA
	Project	Projection rules only configured on the master source. Declared rule.
	Provision	Provision to all target forests.
	Deprovision	Delete from the target forest.
	Object Deletion	Delete when disconnected from the master source.
MasterSite	Connector Filter	NA
	Join	NA
	Project	Projection rules only configured on the master source. Declared rule.
	Provision	Provision to all target forests.
	Deprovision	Do not delete target if there are Server objects under the Site. Provisioning code will handle deletion of child objects.
	Object Deletion	Delete when disconnected from master source
MasterSubnet	Connector Filter	NA
	Join	NA
	Project	Projection rules only configured on the master source. Declared rule.
	Provision	Provision to all target forests.
	Deprovision	Delete from target forest.
	Object Deletion	Delete when disconnected from the master source.
MasterSiteLink	Connector Filter	NA
	Join	NA
	Project	Projection rules only configured on the master source. Declared rule.
	Provision	Provision to all target forests.
	Deprovision	Delete from target forests.
	Object Deletion	Delete when disconnected from the master source.
MasterNTDSSiteSettings	Connector Filter	NA
	Join	NA
	Project	Projection rules only configured on the master source. Declared rule.
	Provision	Provision to all target forests.
	Deprovision	Delete from target forests.
	Object Deletion	Delete when disconnected from the master source.

Table 6 - Metaverse attribute design

Metaverse attribute name	Date type	Indexable Y/N	Multi-Value Y/N	Need to create Y/N
cn name UNCName versionNumber Location serverName portName driverName priority printBinNames printMaxResolutionSupported printOrientationsSupported printCollate printColor printShareName printSpooling printKeepPrintedJobs driverVersion printMaxXExtent printMaxYExtent printMinXExtent printMinYExtent printStaplingSupported printMemory printMediaReady printMediaSupported printerName url shortServerName PrintDuplexSupported Flags printStartTime printEndTime printLanguage printRate printRateUnit printNumberUp printPagesPerMinute description managed-by siteobject siteList cost repl-Interval options schedule siteLinkList DNComponent	String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String String	Y N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N Y N N Y N N N N N N	N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N nb Y N N N N N N	N Y Y Y N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N Y Y Y Y Y Y Y Y Y

Table 7 - Join rules

Source Object type	Metaverse object type	Mapping Type	Match on:
Printqueue	MasterPrintqueue	Direct	CN
Site	MasterSite	Direct	CN
Subnet	MasterSubnet	Direct	CN
SiteLink	MasterSiteLink	Direct	CN
NTDSSiteSettings	MasterNTDSSiteSettings	Direct	CN

Table 8 - Projection rules

Source Object Class	Metaverse Object Type	Declared
Printqueue	MasterPrintqueue	Y
Site	MasterSite	Y
Subnet	MasterSubnet	Y
SiteLink	MasterSiteLink	Y
NTDSSiteSettings	MasterNTDSSiteSettings	Y

Table 9 - Import attribute flow rules

Data source Object	Data source attributes	Metaverse attributes
printqueue	cn name UNCName versionNumber Location serverName portName driverName priority printBinNames printMaxResolutionSupported printOrientationsSupported printCollate printColor printShareName printSpooling printKeepPrintedJobs driverVersion printMaxXExtent printMaxYExtent printMinXExtent printMinYExtent printStaplingSupported printMemory printMediaReady printMediaSupported printerName url shortServerName PrintDuplexSupported Flags printStartTime printEndTime printLanguage printRate printRateUnit printNumberUp printPagesPerMinute	cn name UNCName versionNumber Location serverName portName driverName priority printBinNames printMaxResolutionSupported printOrientationsSupported printCollate printColor printShareName printSpooling printKeepPrintedJobs driverVersion printMaxXExtent printMaxYExtent printMinXExtent printMinYExtent printStaplingSupported printMemory printMediaReady printMediaSupported printerName url shortServerName PrintDuplexSupported Flags printStartTime printEndTime printLanguage printRate printRateUnit printNumberUp printPagesPerMinute
Site	CN description CN	cn description DNComponent (see note)
Subnet	cn description SiteObject	cn description SiteObject
SiteLink	cn description siteList cost replInterval	cn description siteList cost replInterval
NTDSSiteSettings	Cn description	Cn description

Note

The MasterSite DNComponent attribute is created by concatenating the CN of the site with the CN of the target Active Directory container, typically CN=Sites,CN=Configuration.

Table 10 - Object deletion rules

Metaverse object type	Rule:
MasterPrintqueue	Last connector from master source management agent
MasterSite	Last connector space object
MasterSubnet	Last connector from master source management agent
MasterSiteLink	Last connector from master source management agent

Table 11 - Provisioning rules

Scenario	Action
Create a new object in the master source of type: Site Subnet SiteLink	Create a new object in the CN=Sites, CN=Configuration container of each target forest. For a new site, also create a Servers child object and NTDSSiteSettings object
Modify or rename an object in the master source of type: Subnet SiteLink	Replicate the change in each target forest
Delete an object in the master source of type: Site Subnet SiteLink	Delete the object in each target forest For Sites - If no child Servers exist, then delete the object from each target forest. If child Servers exist, then do nothing, and alert target forest admin to delete server. Run synchronization on target forest, then run full synchronization on master source.

Table 12 - Provisioning printer objects

Scenario	Action
Add a new printqueue object	Create a new printqueue object in the user specified container.
Modify or rename a printeQueue object	Replicate the change in the target container
Delete a printqueue object	Delete the printqueue object from the target container

Table 13 - Deprovisioning rules

Management agent	Deprovisioning action
Source	Stage a deletion
Targets	Make a normal disconnector

Table 14 - Export attribute flow

Metaverse attribute	Metaverse object	Target data source attribute	Notes
Flags	MasterPrintqueue	Constant mapping with the numeric value of 3	This is necessary to mark the published printer as "immortal", so that the Active Directory printer pruner service doesn't delete the published printer objects
DNComponent	MasterSite	NA	Only used by the metaverse
SiteList	MasterSiteLink	SiteList	See note for rules extension logic

Note

The logic for the flowing multiple values to the SiteList attribute is as follows:

Clear cs.siteList attribute

foreach member in MV.siteList attribute

cs.siteList.Add(member.StringValue + domainComponent of the forest (configured in XML file)

next

Table 15 - Management agent rights

Scenario	Rights needed
Management agent connections to Active Directory	Replication rights for the Active Directory dirsync control Create/modify/delete on the container and children where info need to be updated.
Management agent access to the master source	Determined by your master source type
Management agent access to Site/Subnet configuration container in the target forests	In addition to above rights: Write control Write property Create/delete child on container, create/delete sites and subnets and sitelink options.

Table 16 - Printer specific rights

Scenario	Rights needed to the user specified printqueue folder
Management agent connected to the master source	List child List object Read control Read property
Management agent connected to target forests	In addition to above rights: Write control Write property Create/delete sites Create/delete printqueue objects.