Module 5: Clustering 3
In Exchange Server 2003, the resource-dependant tree has been altered so that
all Exchange 2003 cluster resources are now directly dependant on the System
Attendant resource.
Here we see that all the Exchange related resources are now directly dependant
on the System Attendant. This effectively means that the SMTP (and other
protocol resources) can now be brought online/go offline in parallel with the
store. This makes for faster failovers of the Exchange Virtual Server.
During the creation of the Exchange Virtual Server process, the correct
dependencies will be set.
The POP3 and IMAP4 resources are not created by default. If they are
created manually, then you will need to set a dependency on the System
Attendant (this is mandatory).
During an upgrade of an Exchange 2000 Exchange Virtual Server, the resource
dependencies will be changed to the new Exchange 2003 resource dependency
tree. From the “Exchange Server Setup Progress.log” file we can see these
changes being made. Open the log file and search for
ScUpgradeResourceDependencies. Here we will see each resource being
changed.
An SMTP resource being changed from the progress log:
Resource Dependency
Tree in Exchan
g
e 2003
Note
4 Module 5: Clustering
[08:36:54] Entering ScUpgradeResourceDependencies
[08:36:54] Checking dependencies of resource 'SMTP Virtual
Server Instance - (EVS-01)'
[08:36:54] Entering ScChangeResourceDependency
[08:36:54] About to change resource dependency for resource
'SMTP Virtual Server Instance - (EVS-01)'
[08:36:54] Leaving ScChangeResourceDependency
You will see the above entries for all Exchange resources that are upgraded to
Exchange 2003.
Module 5: Clustering 5
Cluster Service Account Permissions
Related articles/bugs:
329702.KB.EN-US
In order to successfully create, delete or modify an Exchange 2000 Exchange
Virtual Server, the Windows 2000 cluster service account required “Exchange
Full Administrator” permissions at the organization level if it was the first
Exchange Virtual Server in the org. If it was not the first Exchange Virtual
Server in the org then it required Exchange Full Administrator on the Admin
Group that it was being installed into.
6 Module 5: Clustering
The Exchange Virtual Server creation process (shown above) can be broken
down as follows:
1. User DOMAIN\Administrator logs in to one of the Nodes and starts Cluster
Administrator (cluadmin.exe). The process cluadmin.exe runs as the
currently logged in user (DOMAIN\Administrator). The Administrator then
attempts to create a new Exchange System Attendant. Excluadmin.dll will
gather information from Active Directory in order to create the System
Attendant (e.g. Org name and Administrative Group name etc). The user
DOMAIN\Administrator needs permissions to read from the configuration
partition of the Active Directory.
2. When excluadmin.dll has collected the necessary information, it will then
pass the information to exres.dll. Exres.dll is the Exchange resource dll.
Exres.dll runs in the Resource Monitor process, which runs in the context of
the Cluster Service Account.
3. Exres.dll will then load exsetdata.dll in order to create the objects in Active
Directory. Exsetdata.dll also runs in the Resource Monitor process.
4. Exsetdata.dll will then create the necessary objects in the Active Directory.
As Exsetdata.dll runs in the context of the Cluster Service Account, this
account will require Full Exchange Administrator permissions in order to
create the objects successfully.
Permission
requirements in
Exchange 2000
Module 5: Clustering 7
In Exchange 2003 the permissions have changed in order to remove this
requirement. Any person or application that runs as the Windows 2000 cluster
service account essentially has the ability to destroy an Exchange 2000
organization.
The Exchange 2003 permissions requirements are as follows:
In the Exchange 2003 the Exchange Virtual Server creation process can be
broken down as follows:
1. The user DOMAIN\Administrator logs in to a Node in the cluster and starts
Cluster Administrator (cluadmin.exe). This process runs in the context of
DOMAIN\Administrator. The Administrator then attempts to create a new
Exchange System Attendant resource. Excluadmin.dll will gather
information from Active Directory in order to create the System Attendant
(e.g. Org name and Administrative Group name etc). The user
DOMAIN\Administrator will need to permissions to read from Active
Directory for this operation to be successful.
2. When excluadmin.dll has collected the necessary information, it will then
load Exsetdata.dll directly. Exsetdata.dll runs in the same process as
Excluadmin.dll (DOMAIN\Administrator).
3. Exsetdata.dll will then create the objects in Active Directory. As
exsetdata.dll runs in the context of DOMAIN\Administrator, it is this
account that requires the Exchange Full Administrator permissions to the
configuration partition of Active Directory.
Permissions
requirements in
Exchan
g
e 2003
8 Module 5: Clustering
After an Exchange 2000 Exchange Virtual Server has been successfully
upgraded to Exchange 2003 the cluster service account for that cluster can
be removed from the organization and/or Administrative Group objects’
permissions using the delegate control wizard. Remember that if that
account is used by other Exchange 2000 clusters, then you will have to
leave the permissions in place until they have been upgraded to Exchange
2003
Windows 2000 Cluster Service Account:
Local Administrator on each Node in the cluster
Exchange Full Administrator on org object if other Exchange 2000 clusters
remain in org
Windows 2003 Cluster Service Account
Local Administrator on each Node
No permissions required on org
Permissions required
quick check:
Module 5: Clustering 9
MsExchange_NodeState
MsExchange_NodeState is a registry value that is set during the installation of
the Exchange 2003 binary files on a cluster Node. It can be seen in the
following screen shot:
In this screen shot we can see that Nodes 1 and 2 have the value set and Nodes
3 and 4 do not.
In Exchange 2000 we did not check if a node in the cluster had the Exchange
binary files installed. This would cause problems when calculating if
Active/Active or Active/Passive was allowed in the cluster.
For example, If we have a three-Node cluster but we have only installed
Exchange 2000 on two of the Nodes, we should be allowed to have an
10 Module 5: Clustering
Active/Active or Active/Passive cluster, as only two of the Nodes can actually
host an Exchange Virtual Server. Unfortunately exres.dll (The Exchange cluster
resource .dll) does not see that one of the Nodes does not have the Exchange
2000 binaries and therefore should not be counted when calculating if
Active/Active or Active/Passive is allowed. In this scenario if we created two
Exchange Virtual Servers and then tried to bring both of them online on one
Node, one of the Exchange Virtual Servers would fail to come online.
In Exchange 2003 we now write this value to the registry on each Node in order
to tell us that the Node is Exchange enabled (i.e. it can be added as a possible
owner of an Exchange 2003 resource).
It is also used to determine the maximum number of Exchange Virtual Servers
that can be created in the cluster.
For example if we have six Nodes in the cluster but only four of them have the
MSExchange_NodeState set to 1, then we can create a maximum of three
Exchange Virtual Servers.
The maximum is three in this example, as we always enforce at least one
passive node in cluster with greater than two Nodes.
The registry value is written to the following location:
HKLM\Cluster\Nodes\<Node_ID>\Parameters\MSExchange_NodeState
REG_DWORD=1
The Node_ID value is set when the node is added as a member of the
cluster. The first node in a cluster will always have a Node ID of 1.
When the value is set to 1, then the node is Exchange 2003-enabled and can be
set as a possible owner of Exchange 2003 resources in the cluster.
If this value is set to 0 or does not exist, then the Node will not be allowed as a
possible owner for Exchange 2003 resources.
If you attempt to add a cluster node as a possible owner of an Exchange 2003
resource you will receive the following error:
Another registry entry MSExchange_CurrentBuild is used to track the version
of Exchange 2003 that is installed on the Node. For example, if we were to
upgrade the binary files on Node 1 to a higher value than Node 2, then the
MSExchange_CurrentBuild versions would be different on the two nodes.
Note
Module 5: Clustering 11
From the Exchange Server Setup Progress log we can see Setup writing these
attributes:
[02:25:13] Entering
CAtomClusterServer::ScSetExchangeStateOnCluster
[02:25:13] Entering CAtomClusterServer::ScSetNodeProperty
[02:25:13] Setting DWORD MSExchange_NodeState=1 on node
'NODE1'
[02:25:13] Setting DWORD MSExchange_CurrentBuild=452526080 on
node 'NODE1'
[02:25:13] Leaving CAtomClusterServer::ScSetNodeProperty
[02:25:13] Leaving
CAtomClusterServer::ScSetExchangeStateOnCluster
[02:25:13] Entering
CAtomClusterServer::ScEnableNodeAsPossibleOwer
[02:25:13] Leaving
CAtomClusterServer::ScEnableNodeAsPossibleOwer
This can also be seen from the cluster log:
00000550.00000308::2003/04/20-00:25:13.497 INFO [DM] Setting
value of MSExchange_NodeState for key Nodes\1\Parameters to
0x00000001
00000550.00000308::2003/04/20-00:25:13.497 INFO [DM] Setting
value of MSExchange_CurrentBuild for key Nodes\1\Parameters to
0x1af90000
12 Module 5: Clustering
DNS registration/Kerberos
Related articles:
Article 235529
Windows 2000 SP3 added support for Kerberos authentication against clustered
virtual servers. Prior to Windows 2000 SP3, all authentication against clustered
virtual servers was NTLM or NTLM version 2 (NTLMv2). Prior to Windows
2000 SP3, a clustered virtual server did not have a corresponding Active
Directory computer object. When the RequireKerberos property was set to 1
and the Network Name resource was restarted an Active Directory computer
object would be created.
Support for another property RequireDNS was also added in SP3. This would
mean that the clustered virtual server would have to successfully register its
own host record (A-record) in DNS in order to come online.
Both of these properties are private properties of a Network Name resource and
can be set to either 0 or 1. RequireKerberos and RequireDNS have defaults of 1
and 0, respectively. Setting either of these values to 1 is not supported for an
Exchange 2000 Virtual Server. An Exchange 2000 Network Name resource
required that these properties be set to 0.
Therefore all authentication against Exchange 2000 Virtual Servers is NTLM or
NTLM version 2.
In Exchange 2003 we now enforce the use of Kerberos authentication. This is
done automatically by the setup process for non-clustered servers. For clusters,
these private properties are set during the creation of the virtual server. To view
the properties in Windows 2000 we need to use the command line cluster.exe
tool as follows:
Cluster res “my EVS Network Name” /priv
Windows 2000 SP3
Không có nhận xét nào:
Đăng nhận xét