FSMO Role: Schema Master

Schema Master is another FSMO role which is responsible for making changes to the
Active Directory schema. The schema stores descriptions of all Active Directory classes and
attributes (LDAP://cn=schema,cn=configuration,dc=<domain>).
Changes to the AD schema are rarely made: for example, when you extend the schema
using adprep/forestprep, upgrade the domain functional level or install Exchange, Lync (or
other enterprise applications that store configuration objects in AD).

Schema Master role

In the entire AD forest, there can be only one domain controller which is the Schema Master
role owner. Only this domain controller can make changes to the Active Directory schema.
After the schema is updated, it is replicated from the schema master to other domain
controllers in the forest.

The AD schema is a set of objects and their attributes, that are used to store data. In this
case, the AD schema contains the class user, which defines all the attributes of the user
account object.

Each user account in the domain can have all these attributes. But attribute values may not
be specified. You can check which attributes have an account of any domain user and their
values (for example, built-in administrator account).
To do this, open the adsiedit.msc console and connect to the Default naming context. In
the hierarchy, find the user object and open its Properties.

You can see that the object has all the attributes that are defined in the user class (note the
Filter button, you may have turned on display only attributes that have values).
Microsoft recommends the following best practices in the placement and administration of
the Active Directory schema:

1. Always make a backup before changing the schema. Before the process of schema
changes, you can turn off all the domain controllers, of course except for a one, who is
the owner of a Schema Master role. After that, make a backup of the domain controller,
perform all the necessary changes and, in case everything is well, simply turn on all
DCs. If something went wrong, just restore the running controller from a backup, turn on
the rest and then explore the problem.
2. It is recommended to keep the Domain Naming Master and Schema Master roles on
the same DC (they are rarely used and should be tightly controlled), that should
simultaneously be a Global Catalog (GC) server.
3. If you have lost the server with Schema Master role for some reason, you can seize this
role to any other domain controller. But keep in mind that the original Schema Master
should not appear on the network after that.
4. Perform schema changes manually only in case of extra need. If this still needs to be
done in any case, see paragraph 1.
If the DC owner of a Schema Master role is unavailable, it is not possible to change the AD
schema. However, the upgrade of the schema is usually not done often (as a rule when
installing new DCs with a newer Windows Server version or installing some other server
products, such as Exchange). In practice, the absence of a schema master can be
overlooked for years.

To manage AD schema and transfer the Schema Master role between domain controllers,
use the Active Directory Schema mmc snap-in. However, to enable this console you must
register the dynamic library Schmmgmt.dll at first.
1. Open elevated Command prompt.
2. Execute the command:

regsvr32 schmmgmt.dll
Tip. To manage an AD schema you must be a member of the Schema Admin group.
То transfer Schema Master FSMO role you need to start AD Schema console.

1. Open mmc.exe
2. Click File -> Add/Remove snap-in.
3. Select Active Directory Schema item and press Add -> Ok.

4. Right click on the root of the console, select Change Active Directory Domain
controller and select the DC on which you want to transfer the role.
5. Next select Operation Masters and press Change button.
Tip. You can’t change Schema Master role owner from source server.

6.1.5.2 Domain Naming Master FSMO

Role
The Domain Naming Master FSMO role owner is the DC responsible for making
changes to the forest-wide domain name space of the directory in the Partitions
container. This DC is the only one that can add or remove a domain or application
NC from the directory. It can also add or remove cross references to domains in
external directories. Only the Domain Naming Master FSMO role owner can write to
the Partitions container or its children. There is only one Domain Naming Master
FSMO role per forest.

MCSA/MCSE 70-291: The Dynamic Host Configuration

Protocol
Deborah Littlejohn Shinder, ... Laura Hunter, in MCSA/MCSE (Exam 70-291) Study
Guide, 2003
Enterprise Admins Group
The Enterprise Admins group is often called the “all powerful” group in the Active
Directory environment. There is good reason for this, because members of this
group have the ability to do whatever they want on an enterprise or forest-wide level.
This includes full rights over the DHCP servers. One special feature of this group is
that it is the only Active Directory group that has the right to authorize a DHCP
server. Because the Enterprise Admins group does have so much power over the
network, it is a good idea to restrict membership in this group to members of the
organization’s Active Directory enterprise design team. Even then, in most cases
membership should be limited to only a few members of that team, with the actual
number depending on the size of the organization.
Read full chapter
MCSA/MCSE 70-294: Working with Trusts and
Organizational Units
Michael Cross, ... Thomas W. Shinder Dr., in MCSE (Exam 70-294) Study Guide,
2003
Creating, Verifying, and Removing Trusts
Trust relationships are created and managed using the Active Directory Domains
and Trusts utility in the Administrative Tools menu. To create or manage trusts, you
must be a member of the Domain Admins group or the Enterprise Admins group in
the Active Directory, or have the appropriate authority delegated to you.
Most administrators will use the RunAs command to manage trusts. This is
generally accepted as a security best practice.
Exercise 5.01
Creating a Transitive, One-Way Incoming Realm Trust
1.
Open Active Directory Domains and Trusts by clicking Start | Programs |
Administrative Tools, and then selecting Active Directory Domains and
Trusts.
2.
In the console tree, right-click the domain node. Select Properties in the
context menu.
3.
On the Trusts tab, click the New Trust button.
4.
When the New Trust Wizard opens, click Next.
5.
On the Trust Name page, enter the target realm's name and click Next.
6.
On the Trust Type page, select Realm Trust and click Next (see Figure 5.7).
Sign in to download full-size image
Figure 5.7. Trust Types
7.
On the Transitivity of the Trust page, click Transitive, and then click Next
(see Figure 5.8).

Sign in to download full-size image

Figure 5.8. Transitivity of Trust
8.
On the Direction of Trust page, click One-way: incoming, and then click Next
(see Figure 5.9).
 Sign in to download full-size image
Figure 5.9. Direction of Trust
9.
On the Summary page, review the information, and then click Finish.

This wizard will allow you to also create non-transitive trusts and two-way and one-
way outgoing realm trusts. Alternatively, you can use the netdom command to
create a realm trust.
Read full chapter
MCSA/MCSE 70-294 Working with User, Group, and
Computer Accounts
Michael Cross, ... Thomas W. Shinder Dr., in MCSE (Exam 70-294) Study Guide,
2003
Creating Accounts Using Active Directory Users and Computers
Active Directory Users and Computers is a tool that is installed on DCs, and is used
by those with the appropriate access to create domain accounts. Only members of
the Administrators group, Account Operators group, Domain Admins
group, Enterprise Admins group, or someone who’s been delegated authority can
create a user account. When someone is delegated authority to perform a task, it
means that he or she been given administrative credentials to carry out the action.
Responsibility can be delegated through the Delegation of Control Wizard, Group
Policy, or security groups (which we’ll discuss later in this chapter).
Active Directory Users and Computers is started in a number of ways. As we saw
in Chapter 1, the Active Directory Users and Computers snap-in can be loaded
into Microsoft Management Console (MMC). Using the Windows Start menu can
also start this tool by clicking on Start | Administrative Tools | Active Directory Users
and Computers. The final method of starting it is through the Control Panel.
In Control Panel, open Performance and Maintenance | Administrative Tools |
Active Directory Users and Computers.
Once Active Directory Users and Computers is open, expand the domain in which
you have access, and want to create the account. Within the domain, you select the
container in which you want to create the user object. You can create accounts at
the domain level, use an existing default container (such as Users), or use an OU
that you’ve created. Once you’ve selected the container, click Action |
New | User. InetOrgPerson accounts can also be created this way, by
selecting InetOrgPerson instead of User from Action | New.
Once the User menu command has been clicked in the Action | New menu, a
wizard will start that will take you through the steps of creating a new account. As
shown in Figure 2.6, the first screen provides a number of fields in which you can
enter information relating to the new user:

Sign in to download full-size image

Figure 2.6. Screen Used to Enter New User Information When Creating a New User Object
■
First name The given name of the user.
■
Initials The middle initial(s) in the user’s name.
■
Last name The surname of the user.
■
Full name The entire name of the user. As you enter the user’s first name,
initials, and last name, this field will automatically be filled. It can, however, be
modified. This name must be unique to the container in which the account is
being created.
■
User logon name The UPN that the user will enter to log on to the domain.
The UPN (remember, this is comprised of the user logon name and the UPN
 suffix) must be unique to the enterprise. In other words, two logon names that
are the same cannot exist within the same Active Directory forest. The drop-
down list in this field allows you to select a UPN suffix.
■
User logon name (pre-Windows 2000) The NetBIOS name that the user will
use when logging on to the domain from pre-Windows 2000 operating
systems.
Once you have entered this information, click the Next button to continue providing
information to setup the account.
The screen that follows allows you to configure password information for the user’s
account. As with the previous screen, a number of fields can be used to manage the
initial setup of the account. These fields are depicted in Figure 2.7, and consist of:

Sign in to download full-size image

Figure 2.7. Screen Used to Enter Password Options When Creating a New User Object
■
Password The password that the user will enter, so he or she can be
authenticated.
■
Confirm Password The same password that’s entered in the Password field.
Confirming the password a second time ensures that it has been entered
correctly.
■
User must change password at next logon Checking this box requires the
user to change his or her password at first logon. Having the user change the
password, ensures that only the user knows the new password and is a good
security practice. This setting is enabled by default.
■
 User cannot change password When selected, this ensures that only
administrators can change the user’s password. This can be used if the
account is being used by more than one person (such as a Guest account),
services, or programs. This setting is also used in more secure
environments that require a guarantee of password strength. In these
environments, administrators are often responsible for maintaining
and changing passwords to ensure they meet security standards.
■
Password never expires This setting exempts the user’s password from the
maximum password age Group Policy setting that is enabled for the domain.
This is helpful if a service or program is using the account. If the User must
change password at next logon option is set, this option is overridden.
■
Account is disabled This check box is used to prevent a user from logging
on with this account. This can be used if an employee has been terminated, is
on extended leave or vacation, or hasn’t started in his or her job yet.
After entering this information, click the Next button to reach the final screen for
creating a new user account.
As shown in Figure 2.8, the final screen used in creating a new user object provides
summary information. The information that appears on this screen provides a recap
of the user information and password options that will be used for creating the
account. After the Finish button is clicked, the account is then created in the
container you initially chose to store the object.

Sign in to download full-size image

Figure 2.8. Summary Screen of New Object Dialog Box
Now that we’ve looked at how to create a user account, let’s put that knowledge to
practice and create one in the Exercise 2.02.
Exercise 2.02
Creating a User Object in Active Directory Users and Computers
1.
Open Active Directory Users and Computers from Start | Administrative
Tools Active Directory Users and Computers.
2.
When the utility opens, expand the console tree so that your domain and the
containers within it are visible.
3.
Select the TestOU OU that you created in Chapter 1 from the console tree.
From the Action menu, select New | User.
4.
When the New Object - User dialog box appears, enter the following
information in the corresponding fields:

Field Data to Enter

First name John
initials Q
Last name Public
Full name John Public
User logon name Jpublic
User logon name (pre-Windows 2000) Jpublic
5.
After entering this information, click the Next button to continue.
6.
Enter a password of your choosing in the Password field, and then reenter it
in the Confirm password field.
7.
Clear the User must change password at next logon check box.
8.
Click Next to continue. When the summary screen appears, review the
settings you have entered and click Finish to create the account.
9.
From the Action menu, select New | User.
10.
When the New Object - User dialog box appears, enter the following
information in the corresponding fields:

Field Data to Enter

First name Jane
Last name Doe
Full name Jane Doe
 Field Data to Enter
User logon name Jdoe
User logon name (pre-Windows 2000) Jdoe
11.
After entering this information, click the Next button to continue.
12.
Enter a password of your choosing in the Password field, and then reenter it
in the Confirm password field.
13.
Click Next to continue. When the summary screen appears, review the
settings you have entered and click Finish to create the account.
14.
Log off and then log back on as the jdoe user. Notice that you are required to
change the password.
15.
Log off and then log back on as the jpublic user. Notice that you aren’t
required to change the password.

Read full chapter

MCSA/MCSE 70-294: Working with Global Catalog
Servers and Schema
Michael Cross, ... Thomas W. Shinder Dr., in MCSE (Exam 70-294) Study Guide,
2003
Working with the Active Directory Schema
7.
You are working with the Schema Admin snap-in and cannot make any
changes. You created a network administrator equivalent account in the forest
root domain but cannot modify the schema. Why?
A.
You must be a member of the Enterprise Admin group to modify the schema.
B.
You must be a member of the Schema Admin group to modify the schema.
C.
You must be a Domain Admins member in each domain in the forest to
modify the schema.
D.
Only the initial Administrator account during forest creation can modify the
schema.
8.
You are a network administrator and you want to modify an attribute that is
associated with one of your user accounts. How do you do this?
A.
Open Active Directory Users and Computers and change to advanced view.
This will allow you to modify the properties of the attributes in the user
account for which you need to make the change.
B.
Open Active Directory Sites and Services. Open the Properties for the site
containing the attribute and make the modifications.
C.
Open the Schema Snap-in, expand Objects, and select the User object to
modify the associated attributes.
D.
Open the Schema Snap-in, expand Attributes, and find the attribute you
want to modify.
9.
You are explaining the various attributes to a fellow network administrator.
You are showing her the properties of a User account, and your new network
administrator asks what the Other button means with regard to various
attributes. What do you tell her?
A.
Those attributes are multivalued attributes.
B.
Those attributes are single-value attributes.
C.
Those attributes are actually Object classes.
D.
Those attributes are Index attributes.
10.
As a network administrator, you are responsible for making sure that various
attributes are indexed for optimal performances for queries. What steps do
you take to make an attribute indexed?
A.
Using the Schema snap-in, right-click the attribute you want to index and
select Properties. Select Index this attribute in the Active Directory.
B.
Using the Schema snap-in, right-click the attribute you want to index and
select Properties. Select Replicate this attribute to the GC.
C.
Using the Schema snap-in, right-click the attribute you want to index and
select Properties. Select Allow this attribute to be shown in advanced
view.
D.
Using the Schema snap-in, right-click the attribute you want to index and
select Properties. Select Attribute is Active.
11.
You are working with Schema objects and you need one component that has
to be supplied by a third-party. Which component is supplied by a third party
so standards can be followed?
A.
LDAP name
B.
Common name
C.
OID
D.
Object GUID
12.
You make a mistake while setting up new classes in your schema. You want
to correct the mistake so you can have the appropriate name and
configuration for the class. How do you do this?
A.
You must deactivate the class that was added with the mistake and then
rename it. You then can create a new class with the appropriate name and
configuration.
B.
You must delete the class that has the mistake and simply create the
appropriate Class object.
C.
You must wait 24 hours before you can delete any new classes in the
schema. You can then delete the class and create the corrected Class object.
D.
You can go in and fix the existing Class object without having to recreate the
object.
13.
You have an office with three locations separated by 56 K WAN links. You are
experiencing slow queries when looking for objects in the Active Directory.
 You have one GC server at your main office. What can you do to improve
the query performance?
A.
Add GC servers to your other two locations.
B.
Add DCs that are not GC servers to your other two locations.
C.
Add a DNS server for faster resolution at your other two locations.
D.
Add another OU to the directory to separate the locations by OU.
14.
You have been experiencing a large amount of processor utilization on your
GC server. Your network consists of one location with 2500 users. You
currently have three DCs for fault tolerance and load balancing. What can you
do to help with your GC server processor utilization?
A.
Add a fourth DC to the network.
B.
Add another GC server to the network to offload some of the traffic.
C.
Remove one DC from the network.
D.
Split your network into three OUs with less than 1000 users each.
15.
You are working on updating the schema and cannot associate an attribute
with a class. What can you do to resolve this?
A.
Add yourself to the schema Admins group.
B.
Makes sure the Schema Operations Master is online and reachable.
C.
Reload the schema in the Schema admin tool.
D.
Move the role of Schema Operations Master.
Read full chapter
The WMI Providers
Alain Lissoir, in Leveraging WMI Scripting, 2003
3.6.1.3 Monitoring Active Directory group memberships
Everybody knows the importance of Active Directory group memberships, right? It is
clear that some Active Directory groups are more sensitive than others from a
security point of view. For example, you wouldn't want to see just anyone added to
the “Enterprise Admins” group without appropriate control, would you? No, of course
you wouldn't! Well, with the Active Directory provider and a WQL event query, it is
possible to get a WMI event notification when a modification is made to a group or
any other object of Active Directory. The WQL event query to use should be as
follows:

Sign in to download full-size image

Directly inspired from Samples 6.18 through 6.21 (“Monitoring, managing, and
alerting script for the Windows services”) in the appendix, Sample 3.54 is an
immediate application of this WQL Event query example.
Sign in to download full-size image
Sign in to download full-size image
Sign in to download full-size image
Sample 3.54. Monitoring, managing and alerting script for the Windows Group modifications
As usual, the script structure is always the same. The script starts with the
command-line parameter definitions (skipped lines 13 through 18) and parsing (lines
69 through 86). The script requires only one parameter on the command line, which
lists one or more Active Directory group names to monitor. For example, to monitor
modifications on the “Enterprise Admins” and “Domain Admins” group, the command
line will be:

Sign in to download full-size image

The groups given on the command line are stored in an array (lines 75 through 78).
Once the WMI connection is established (lines 90 through 93), the WQL query is
constructed in a loop between lines 96 and 107. For the two sample groups given on
the command line, the resulting WQL query will be:

Sign in to download full-size image

Next, the WQL query is submitted for asynchronous notifications (line 111), and the
script enters an idle state. Once a modification is made to one of the given groups,
the event sink routine (lines 127 through 167) is invoked, and the script immediately
sends an email alert by reusing the SendMessage() function (included at line 23) and
the GenerateHTML() function (included at line 22). The PreviousInstance and
the TargetInstance properties containing object instances are formatted in HTML and
stored in a MIME body mail message.
Read full chapter
Introducing Exchange Server 2007 SP1
Fergus Strachan, in Integrating ISA Server 2006 with Microsoft Exchange 2007,
2008
Schema
SP1 requires an extension to the Active Directory schema, so this is the first task to
be undertaken. This will be done automatically by the setup program when you
upgrade the first Exchange server, although the user must be a member of the
Schema Admins and Enterprise Admins groups in the forest.
To update the schema in preparation for the upgrade, use the same method as for
RTM—Setup /PrepareSchema.
Active Directory
Some aspects of Active Directory must also be updated, as for RTM, by using the
Setup /PrepareAD command. This will also be done as part of the first server
upgrade providing the user is a member of the Enterprise Admins group.
Domains
SP1 also requires changes to each domain in which Exchange items (users,
contacts, etc.) are to be homed. This can be done beforehand using the Setup
/PrepareDomain or /PrepareAllDomains switches. This requires membership of
the Domain Admins group.
Read full chapter
Installing Exchange Server 2007
Henrik Walther, in How to Cheat at Configuring Exchange Server 2007, 2007
Uninstalling Exchange Server 2007
There might be situations in which you want to completely remove an Exchange
2007 server from your Exchange organization. This can be done using either the
Exchange 2007 Installation Wizard or Setup.com.
Uninstalling Exchange 2007 using the Installation Wizard is done the following way:
1.
Log on to the respective server with an account that belongs to the Enterprise
Admins group.
2.
Open the Control Panel.
3.
Click Add or Remove Programs.
4.
Select Microsoft Exchange Server 2007.
5.
Click the Remove button.
6.
 Now clear the check box for each server role, including Management Tools,
and click Next.
7.
When the Readiness check has completed, click Uninstall.
NOTE
To remove the Mailbox server role, you'll need to make sure no mailboxes exist in
the Mailbox database(s) on the respective server. In addition, if you have any Public
Folder databases on the server, you'll need to move any existing offline address
books to a Public Folder database on another server. Also, keep in mind that you will
need to manually delete any EDB and transaction log files after you have uninstalled
Exchange, because this is not done via the Exchange Server 2007 Setup Wizard.

Uninstalling Exchange Server 2007 using the CLI can be done the following way:
1.
Log on to the respective server using an account that belongs to the
Enterprise Admins group.
2.
Click Start | Run, type CMD.exe and click OK.
3.
Now change to the Exchange Bin folder by typing CD C:\Program
Files\Microsoft\Exchange Server\Bin and press Enter.
4.
Type ExSetup.exe /mode:Uninstall.
Removing all server roles from an Exchange 2007 server will also remove
any installation files as well as the Exchange server object and all its child objects
from the Active Directory forest.
Read full chapter
Transitioning from Exchange 2000 or 2003 to Exchange
2007
Henrik Walther, in How to Cheat at Configuring Exchange Server 2007, 2007
Extending the Active Directory
With all prerequisites fulfilled, we can move on and prepare the Active
Directory using the respective Exchange 2007 Setup.exe switches. Exchange 2007
Setup includes several switches; in this section we'll go through each of those
related to preparing the Active Directory.
WARNING
Each of the switches we discuss here will run automatically during the deployment of
the first Exchange 2007 server in the Exchange legacy organization (if the account
you're logged on with has Schema and Enterprise Admin rights!), so it's not
mandatory that you run them before installing Exchange 2007. However, depending
on the size as well as the topology of your environment, it might be wise to prepare
the Active Directory first using these switches before you start the actual deployment
process.
Prepare Legacy Exchange Permissions
The first thing we need to do in deploying an Exchange 2007 into a legacy Exchange
organization is to run Setup.com/PrepareLegacyExchangePermissions, to grant
specific Exchange permissions in the Active Directory domain(s) in which one or
more Exchange 2000 or 2003 Servers exists or where Exchange 2000 or
2003 DomainPrep has been executed. The reason we must
run Setup.com/PrepareLegacyExchangePermissions is that the Exchange 2003 or
Exchange 2000 Recipient Update Service won't otherwise function correctly after
the Active Directory schema has been updated with Exchange 2007-specific
attributes.
TIP
For a detailed explanation of
why Setup.com/PrepareLegacyExchangePermissions must be run in an Active
Directory domain in which one or more Exchange 2000 or 2003 Servers exists or
where Exchange 2000 or 2003 DomainPrep has been executed, search for
“preparing legacy Exchange permissions” in the Exchange 2007 Documentation
found at www.microsoft.com/technet/prodtechnol/exchange/e2k7help.
To run Setup.com /PrepareLegacyExchangePermissions, you must open
a Command Prompt window and navigate to the directory, network share, or DVD
media containing your Exchange 2007 Setup files, then simply
type Setup.com/PrepareLegacyExchangePermissions followed by
pressing Enter, as shown in Figure 10.7. Bear in mind that the account you're logged
on with must be a member of the Enterprise Admins group.

Sign in to download full-size image

Figure 10.7. Preparing Legacy Exchange Server Permissions
SOME INDEPENDENT ADVICE
Some of you might be in a situation where you want to prepare the Active Directory
domain before you install the x64-bit version of Windows Server 2003 on a server in
the Active Directory forest, and therefore you cannot run Setup.com
/PrepareLegacyExchangePermissions using the 64-bit version of Exchange 2007
because you don't have any x64-bit Windows 2003 Servers deployed yet. But fear
not—using the 32-bit version of Exchange 2007 to prepare your production Active
Directory environment is fully supported. As mentioned in the introduction to this
chapter, the 32-bit version of Exchange 2007 is not supported in a production
environment except for management tasks, and preparing the Active Directory is
considered a management task.
Prepare Schema
The next command to run to prepare the environment is Setup.com
/PrepareSchema, which will connect to the domain controller schema master and
import LDAP files to update the schema with Exchange 2007-specific attributes. To
do so, open a Command Prompt window and type Setup.com
/PrepareSchema followed by pressing Enter, as we did with the previous switch.
Setup will now update the schema as necessary, as shown in Figure 10.8. To run
this command, the account you're logged on with must be a member of both the
Enterprise and Schema Admins groups.

Sign in to download full-size image

Figure 10.8. Running Setup.com with the PrepareSchema Switch
Prepare AD
The Setup.com /PrepareAD command is used to configure global Exchange objects
in Active Directory, create the Exchange Universal Security Groups (USGs) in the
root domain, and prepare the current domain. The global objects reside under the
Exchange organization container. In addition, this command creates the Exchange
2007 Administrative Group, which is named Exchange Administrative Group
(FYDIBOHF23SPDLT), as well as creating the Exchange 2007 Routing Group,
called Exchange Routing Group (DWBGZMFD01QNBJR).
You can run the Setup.com /PrepareAD command before
running /PrepareLegacyExchangePermissions and /PrepareSchema, as shown
in Figure 10.9. Doing so will run
the /PrepareLegacyExchangePermissions and /PrepareSchema commands
automatically. Running this command requires you log on with an account that is a
member of the Enterprise Admins group.

Sign in to download full-size image

Figure 10.9. Running Setup.com with the PrepareAD Switch
As you might be aware, Exchange 2007 doesn't use Routing Groups and
Administrative Groups, as Exchange 2000 or 2003 did. Administrative Groups have
been dropped completely, and message routing in Exchange 2007 is based on
Active Directory sites. But for Exchange 2007 to c-exist with Exchange 2000 or 2003,
Exchange must create the mentioned Administrative Group and Routing Group,
which can only be viewed via an Exchange 2000 or 2003 System Manager or by
using ADSI Edit, as shown in Figures 10.10 and 10.11.

Sign in to download full-size image

Figure 10.10. Exchange 2007 Administrative and Routing Group in the Exchange 2003 System Manager
Sign in to download full-size image
Figure 10.11. Exchange 2007 Administrative and Routing Groups in ADSI Edit
SOME INDEPENDENT ADVICE
Okay, with all these boring switches, it's time for a little fun! Did you know that
although coding a product such as Exchange 2007 is a lot of hard work, the
Exchange Product Group always has time for a little humor? To prove it, let's take
the GUID of the Administrative Group shown in Figure 10.10 and shift each letter
upward. Now do the same for the GUID of the Exchange Routing Group shown
in Figure 10.11, but do it downward. Did you manage to see what it translates to?
Yes, it's EXCHANGE12ROCKS!
For those who don't know, “Exchange 12” was the codename for Exchange
Server 2007 until the product got a real name in April 2006.
PrepareDomain and PrepareAllDomains
It's also possible to prepare a local domain or all domains in the Active Directory
using the Setup.com /PrepareDomain and Setup.com /PrepareAllDomains,
respectively. These switches will set permissions on the Domain container for
the Exchange servers, Exchange Organization Administrators, Authenticated Users,
and Exchange Mailbox Administrators; create the Microsoft Exchange System
Objects container if it does not exist; set permissions on this container for the
Exchange servers, Exchange Organization Administrators, and Authenticated Users;
and in the current domain, create a new domain global group called Exchange
Install Domain Servers. In addition, it will add the Exchange Install Domain Servers
group to the Exchange Servers USG in the root domain.
Like the commands we've already been through, these commands also need to be
run from a Command Prompt window, as shown in Figure 10.12.

MCSE/MCSA 70–294: Working with Domain Controllers

Michael Cross, ... Thomas W. Shinder Dr., in MCSE (Exam 70-294) Study Guide,
2003
Transferring the Schema FSMO
First, you must be a member of the Schema Admins group. Next, you need to
access the Active Directory Schema snap-in, which is not in the Administrative
Tools menu but must be added to an MMC.
To install the Active Directory Schema snap-in, follow these steps:
1.
Open a command prompt [Start | Run | cmd, and click OK.
2.
At the command prompt, type regsvr32 schmmgmt.dll. This command will
register schmmgmt.dll on your computer. Successful registration produces the
dialog box shown in Figure 7.28.

Sign in to download full-size image

Figure 7.28. Register Service
3.
 Click Start | Run… and type mmc /a. Then, click OK. This opens a blank
MMC in author’s mode.
4.
On the File menu, click Add/Remove Snap-in, and then click Add.
5.
Under Snap-in, double-click Active Directory Schema, click Close, and then
click OK.
Looking at the schema attributes, you can identify a few Figure 7.29 shows
the cn or Common-Name attribute, which is mandatory in a user account. Right-
clicking on the object named Active Directory Schema affords you several options
(see Figure 7.30). From this tool, you can see which DC is currently assigned the
Schema Master by selecting Operations Master…, and you can transfer the FSMO
to another DC by selecting Change Domain Controller.

Sign in to download full-size image

Figure 7.29. Active Directory Schema Tool

Sign in to download full-size image

Figure 7.30. Management Options
Figure 7.31 depicts the next dialog in our quest. You are then given the choice to
transfer the FSMO to Any DC or Specify a Name. Specify the new location and
click OK. The new location is the FQDN of the DC to which you are transferring the
FSMO. The system will refresh the screen and you will see that the focus has
changed to the other DC you just specified (see Figure 7.32). To complete the task,
you still need to right-click the Active Directory Schema object again, and this time
choose Operations Master, which brings up the dialog box shown in Figure 7.33. In
our example, we are moving the schema FSMO to the DC, skyline.yourfim.biz.
Click Change and the system will ask you to verify that you really want to make this
change. Click OK. After a short pause, the confirmation dialog
in Figure 7.34 appears. Click OK. The Schema FSMO is now on the
skyline.yourfirm.biz DC.

Sign in to download full-size image

Figure 7.31. Change Domain Controller

Sign in to download full-size image

Figure 7.32. Change in Focus Prior to FSMO Transfer

Sign in to download full-size image

Figure 7.33. Change Schema Master
Sign in to download full-size image
Figure 7.34. Confirmation of FSMO Transfer
Configuring & Implementing…
Finding FSMO
If all you ever do is go with the defaults, you probably know where all the FSMOs
are. However, there is a good chance of inheriting someone else’s undocumented
domain or walking into a foreign network as the perceived network guru. In these
cases, you need to know how to find FSMOs. Microsoft has a tool to do just
that: www.microsoft.com/windows2000/techinfo/reskit/tools/existing/dumpfsmoso.as
p. Okay, so the tool is not that impressive when you edit the *.cmd file, but the
information is. Here are the steps to get a list of the FSMO roles and who has them:
1.
Make sure you are logged on as either the local BuiltIn\Admimstrator for local
access or Domain\Administrator or Enterprise\Administrator for remote
access.
2.
Open a command prompt: Start | Run | “cmd” | OK.
3.
If you have access to the dumpfsmos.cmd, go ahead and run it and you are
finished; however, you can do the same thing manually by reading on…
4.
At the command prompt, type the following (bold text indicates what you
should type, the rest depicts the DC’s responses. Note that indents and
bolding have been added for emphasis and easier reading):
C:\>ntdsutil roles connections
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server skyline
Binding to skyline…
Connected to skyline using credentials of locally logged on user.
server connections: quit
fsmo maintenance: select operation target
select operation target: list roles for connected server
Server “skyline” knows about 5 roles
Schema - CN=NTDS Settings, CN = SKYLINE,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=yourfirm,DC=biz
Domain - CN=NTDS Settings,CM = TEKEASE-DC1,CN=Servers,CN=Default-First-
Site-Name,CN=Sites,CN=Configuration,DC=yourfirm,DC=biz
PDC - CN=NTDS Settings,CN = TEKEASE-DC1,CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=yourfirm,DC=biz
RID - CN=NTDS Settings,CN-TEKEASE-DC1,CN=Servers,CN=Default-First-Site-
Name,CN=Sites, CN=Configuration,DC=yourfirm,DC=biz
Infrastructure - CN=NTDS Settings,CN = TEKEASE-DC1,CN=Servers,CN=Default-
First-Site-Name,CN=Sites,CN=Configuration,DC=yourfinn,DC=biz
select operation target: quit
fsmo maintenance: quit
ntdsutil: quit
Disconnecting from skyline…
C:\>
From the output of our request, list roles for connected server, we see that the
Schema FSMO is on the Skyline DC, which is where we transferred it, and the other
four FSMOs remain on the original DC, tekease-dc1. Ntdsutil is a great tool, so learn
how to use it.
Another tool you can use uses VBScripting as a GUI approach to the same goal:
finding FSMO. This tool is user friendly by generating a pop-up dialog for your input
of a server, and then displaying five pop-up dialogs, each with the location of a
FSMO. Try searching the internet for “finding fsmo vbs,” or go
to www.serverwatch.com/tutorials/article.php/10825_1472341_5.

Read full chapter

MCSE 70-293: Planning, Implementing, and Maintaining
a Security Framework
Martin Grasdal, ... Dr.Thomas W. Shinder, in MCSE (Exam 70-293) Study Guide,
2003
Securing the Schema
ACLs are used to protect schema objects from unauthorized use in AD. Members of
the Schema Admins group are the only members permitted to have write access to
the schema. The only default member of the Schema Admins group is
the Administrator account in the root domain of the forest.
You should restrict membership in the Schema Admins group, because extending
the schema improperly can have serious consequences to your network. For
example, an improper change to the schema can cause existing objects in the
directory to become invalid. If you disable a particular attribute in an object class and
there are existing objects in that class that contain that attribute, these objects will
become invalid because they contain an attribute that is not allowed in the class
definition.
Read full chapter
Configuring the Active Directory Infrastructure
Tony Piltzecker, Brien Posey, in The Best Damn Windows Server 2008 Book Period
(Second Edition), 2008
Locating and Transferring the Schema Master Role
The DC that hosts the Schema Master role controls each update or modification to
the schema. You must have access to the Schema Master to update the schema of
a forest.
Note
You must be a member of the Schema Admins group to perform this operation. The
built-in Administrator account in the forest root domain is automatically configured as
a member of this group when the Active Directory forest is created.

Temporary loss of the Schema Master is not noticeable to domain users. Enterprise
and domain administrators will not notice the loss either, unless they are trying to
install an application that modifies the schema during installation or trying to modify
the schema themselves. You should seize the schema FSMO role to the standby
operations master only if your old Schema master will be permanently offline.
Configuring & Implementing…
Locating the Schema Operations Master
1
Log on as an Enterprise Administrator in the forest you are checking.
2
Click Start | Run
3
Type regsvr32 schmmgmt.dll in the Open box, and click OK. This registers
the Schmmgmt.dll.
4
Click OK in the dialog box showing that the operation succeeded.
5
Click Start | Run, type mmc, and then click OK
6
On the menu bar, click File | Add/Remove Snap-in, click Add, double-
click Active Directory Schema, click Close, and then click OK
7
 Expand and then right-click Active Directory Schema in the top-left pane,
and then select Operations Masters to view the server holding the Schema
Master role, as shown in Figure 2.6

Sign in to download full-size image

Figure 2.6. The Server Holding the Schema Master Role

Configuring & Implementing…

Transferring the Schema Operations Master Role
1
Log on as an Enterprise Administrator in the forest where you want to transfer
the Schema Master role.
2
Click Start | Run
3
Type regsvr32 schmmgmt.dll in the Open box, and then click OK. This
registers the Schmmgmt.dll.
4
Click OK in the dialog box showing that the operation succeeded.
5
Click Start | Run, type mmc, and then click OK
6
On the menu bar, click File | Add/Remove Snap-in, click Add, double-
click Active Directory Schema, click Close, and then click OK
7
Right-click Active Directory Schema in the top-left pane, and then
click Change Active Directory Domain Controller
8
 As shown in Figure 2.7, select the This Domain Controller or AD LDS
instance, enter the name of the DC that will be the new role holder, and then
click OK.

Sign in to download full-size image

Figure 2.7. Changing an Active Directory Domain Controller
9
Right-click Active Directory Schema again, and then click Operations
Master
10
Click Change
11
Click OK to confirm that you want to transfer the role, and then click Close.

Read full chapter

MCSA/MCSE 70-294: Working with Global Catalog
Servers and Schema
Michael Cross, ... Thomas W. Shinder Dr., in MCSE (Exam 70-294) Study Guide,
2003
Single-Value Attributes
Most of the attributes you will work with will be single-value attributes. A single-value
attribute is just what its name implies; it is an attribute with one piece of data entered.
An example would be First Name. The First Name attribute cannot hold multiple
values of data. After the first name is entered, you have to create a completely
different object if you want to have another object with a different First
Name attribute.
Head of the Class…
Schema Administration
When working with the schema, you have to be very cautious about making
changes. In most organizations, only a few people have the ability to modify
the Active Directory schema. The Schema Admins group is used to control who has
the authority to make modifications to the schema. In most cases, the administrator
will not be directly making changes. Many times, software that is installed will make
modifications to the schema. Classes and attributes will be added automatically to
help support the application.
Another component that assists in the schema not becoming corrupted or duplicated
in any way is the Single Master Operations Roles feature of your DCs. In every
forest, there is one Operations Master role for schema modifications. When you log
on, you can authenticate and do your administrative work on any DC on the network.
However, when changes are to be made to the schema, the DC you are working on
will contact the DC with the Schema Master role if that DC is not serving in the role
itself. The DC that is the filling the Operations Master role of Schema Master will
then make the actual changes to the schema. Having one DC responsible for this
prevents the possibility of two DCs attempting to write to the schema at the same
time. There can only be one Schema Master for each Windows Server 2003 forest.

Read full chapter

MCSA/MCSE 70-294 Working with User, Group, and
Computer Accounts
Michael Cross, ... Thomas W. Shinder Dr., in MCSE (Exam 70-294) Study Guide,
2003
Administrator
The Administrator account is the first account that’s created when Active Directory is
installed. As we saw in the previous chapter, when you use the Active
Directory Installation Wizard and set up a new domain, this account is created to
give you the access to perform domain configuration. Once created, it can be used
to create and manage security principals and other objects, administer policies,
assign permissions, and other tasks needed in the design and administration of
Active Directory.
The Administrator account has the highest level of access of any default
account created in Active Directory. It is a member of the Administrators,
Domain Admins, Domain Users, Enterprise Admins, Group Policy Creator Owners,
and Schema Admins groups. While we’ll discuss groups later in this chapter, the
default membership in these groups allows the Administrator account to have full
control over Active Directory. Because these groups provide the security access
attributed to this account, you can create additional accounts for people who
perform administrative tasks and make them members of these groups to give them
the same abilities as the Administrator account.
Due to the importance of the Administrator account, it cannot be deleted from Active
Directory, or removed from the Administrators group. It can, however, be disabled or
renamed to make it more difficult for unauthorized or malicious users to use this
account by guessing its password.
Configuring & Implementing…
Securing the Administrator Account
Anyone familiar with Windows network operating systems will recognize the
Administrator account as one that’s existed in previous versions. An account called
Administrator has been used in Windows NT, Windows 2000, and Windows Server
2003. Because it is known, it can be a target for hackers, who want to access the
account and obtain full control over the domain.
To protect your system, you should rename and/or disable the Administrator account
after creating other accounts with administrator-level access. By renaming the
account, others won’t know what the account is called, and thereby won’t know
which account to access to obtain this high level of control. By disabling the account,
they won’t be able to use it at all.
To prevent unauthorized users from accessing accounts with administrative
credentials, any accounts that are members of the groups that provide administrator
access should use strong passwords. Strong passwords are more difficult to guess,
and use a combination of three or more of the following keyboard characters:
■
Lowercase letters (a -z)
■
Uppercase letters (A-Z)
■
Numbers (0-9)
■
Special characters (({}[],.< >;:’”?/|\`~!@#$%^&*()_-+=)
While strong passwords can’t be hacked using dictionary attacks that look for
specific words and character combinations in the password, they can still be cracked
using brute-force hacking programs, which try to determine the password by using all
possible combinations of characters in a password. Brute-force hacks can take
a considerable amount of time, but are commonly used to obtain unauthorized
access to an account. To make it more difficult for hackers to access an account
using a brute-force attack, you should use longer passwords that consist of a
minimum of eight characters. In a Windows Server 2003 domain, strong passwords
are enabled in Group Policy as a requirement for all accounts. This means that all
passwords that are created after the installation of Active Directory must use at least
one uppercase character, lowercase character, and numeric character.

Read full chapter

Exchange, Windows, and the Active Directory
Tony Redmond, in Microsoft Exchange Server 2007 with SP1, 2008
2.4.2 Changing the schema
The provision of an extendible schema is a major feature of the Active Directory, but
whereas it is great to be able to customize the Active Directory, the feature
introduces some new issues for consideration. Updating the schema does not
impose a performance penalty. The new attributes occupy no space in the database
unless you populate the attributes with data. Changing the schema is something that
you must treat very seriously and only perform when a change is justified and you
fully understand the ramifications. For this reason, you should not agree to any
change up front with all of the domain administrators. Ideally, someone within the
organization should take responsibility for arbitration of schema changes and anyone
who wishes to make a change should first consult that person. Schema anarchy is
not a pretty sight! For this reason, some companies keep the membership of
the Schema Admins group empty until they know they need to make a change,
whereupon they add the necessary user to the group until after the change and then
they revoke the membership.
Attributes can be single-valued (like your home telephone number) or multi-valued
(like the membership of a group). Before you change the schema to add a new
attribute, you need the following information:
▪
The name of the new attribute and its purpose: In directory terminology, this is
the common name. You can provide a separate description, although in many
cases for the standard set of attributes used by Windows or Exchange, the
description is very similar to the name.
▪
Because the roots of Active Directory are in X.500, each attribute and object
has a unique X.500 object identifier, or OID. A national registration authority,
such as the American National Standards Institute (ANSI),1 issues OIDs. You
 can make up the value for an OID, and as long as the value does not clash
with the OID of another attribute, then you will not have a problem. However,
if an application comes along in the future and attempts to add an attribute
with an existing OID, then you will have a problem and the application will not
be able to add the new attribute to the schema. One method that is
sometimes used is to take the base OID for the DSA provider and append
your company's international telephone number plus some sequence number
to it to create the new OID. This method usually guarantees uniqueness.
▪
The type or syntax of the attribute and its maximum and minimum range: For
example, an attribute held as string values will be stored as Unicode strings
and can range in size from 1 to whatever number of bytes is required to hold
the maximum string length.
▪
Whether or not the Active Directory should replicate the attribute to Global
Catalog servers: Clearly, the more attributes that are replicated, the more data
is transmitted across the network. Some attributes are not required enterprise-
wide and can be restricted to an object's home domain. The Active Directory
has to replicate others, like the attribute that holds details of an Exchange
user's home mailbox server, throughout the forest to enable specific
functionality, like message routing.
▪
Whether the Active Directory indexes the attribute and includes it in the
Ambiguous Name Resolution (ANR) process. Exchange has supported ANR
since Exchange 4.0.
Applications like Exchange often include commands to update the schema in their
installation procedures. Exchange 2007 updates the Active Directory and extends
the schema when you run the Setup program with the /PrepareAD switch. After you
update the schema with /PrepareAD, you can browse through the set of attributes
used by Exchange. Figure 2-7 shows the schema snap-in loaded in an MMC
console. You may find that MMC does not list the schema snap-in when you go to
load it. This is probably because the schema snap-in is not registered for use with
MMC. To solve the problem, issue this command at the command prompt:
Sign in to download full-size image
Figure 2-7. Viewing Exchange attributes in the AD schema

Sign in to download full-size image

The schema is loaded into memory on every domain controller in an area called the
schema cache. To ensure that updates are available promptly, the Active Directory
reloads the schema cache from disk every five minutes. If you update the schema,
you can force the Active Directory to reload the cache immediately from an option in
the Schema snap-in. This ensures that all the changes are active before you attempt
to use them.