Configuration Analyzer for System Center 2012 SP1

Configuration Analyzer for System Center 2012 SP1

Customers have started deploying System Center 2012 SP1 in the production. There might be thought immediately after the deployment:

Is basic server configuration correct?  How can I validate settings and components? Is there any troubleshooting tool available?

The answer is YES!

System Center 2012 SP1 Configuration Analyzer is your first line of defense for troubleshooting issues with System Center 2012 SP1 server-side components. System Center 2012 SP1 Configuration Analyzer is a diagnostic tool that you can use to evaluate important configuration settings for computers that run any of the following System Center 2012 SP1 components:

  • Operations Manager
  • Virtual Machine Manager (VMM)
  • Service Manager
  • Orchestrator (plus Service Provider Foundation)
  • Configuration Manager
  • Data Protection Manager (DPM)

More information on http://technet.microsoft.com/en-us/library/jj992580.aspx

Group Policy Basics

Keep it Simple. The fewer number of Group Policies implemented is better for reducing the administrative burden.

Use the “Default Domain Policy” to only apply domain wide security settings, such as password and auditing policies, nothing more.

Use the default “Authenticated Users” group to apply only site, domain, or OU wide

Use Security Group filtering to apply department, role based, or managed software

Use the Group Policy modeling and logging tools, found in the GPMC in designing new group policies and resolving potential conflicts.

Understand the order of policy application. 1-Local, 2-Site, 3-Domain, 4-OU. (LSDO)

Understand any conflicting settings in the last policy to apply – which is closet to the user/machine object – will override previous settings. Unless a previous policy uses the “No Override” function.

Do not use “Block Policy Inheritance” or “No Override” settings unless you fully understand how they work and the repercussions or using them. Using these options changes the generally understood rules (see above) of group policy processing.

Secure Active Directory.

To secure Active Directory, it is recommended that you implement the  following security guidelines:

Rename or disable the Administrator account (and guest account) in each domain to prevent attacks on your domains.

Physically secure all domain controllers in a locked room.

Manage the security relationship between two forests and simplify security administration and authentication across forests.

To provide additional protection for the Active Directory schema, remove all users from the Schema Admins group, and add a user to the group only when schema changes need to be made. Once the change has been made to remove the user from the group.

Restrict user, group, and computer access to shared resources and to filter Group Policy settings.

Avoid disabling the use of signed or encrypted LDAP traffic for Active  Directory administrative tools.

Some default user rights assigned to specific default groups may allow members of those groups to gain additional rights in the domain, including administrative rights. Therefore, your organization must equally trust all personnel that are members of the Enterprise Admins, Domain Admins, Account  Operators, Server Operators, Print Operators and Backup Operators groups.

Use global groups or universal groups instead of domain local groups when specifying permissions on domain directory objects replicated to the global catalog.

Designing groups and organizational units

With the proper preparation and advance knowledge of their use, a functional organizational unit (OU) and group design can do wonders to simplify your Active Directory environment. It can also go a long way toward helping you gain control and reduce overhead.

Often, OUs are indiscriminately used without reason, and group structure is ineffectual and confusing. Without some form of logical organization of users within your network environment, chaos reigns and administration grinds to a halt. Some best practices when designing OUs include:

  • Keep the OU structure as simple as possible
  • Do not nest OUs more than 10 layers deep
  • Keep the number of OUs to a minimum
  • Apply Group Policy to groups through Group Policy filtering
  • Don’t utilize local groups for permissions in a domain environment
  • Use domain local groups to control access to resources, and use global groups to organize similar groups of users

You also have the option of hiding your OUs. The primary purpose of hidden OUs is to prevent an administrator from one OU from being able to view, access, or alter another OU. Hidden OUs are often used in environments that offer network application services to internal departments or external customers. It allows for a solid separation of duties without requiring separate domains or forests.

Active Directory domain design

When you are designing your Active Directory network, it is important to use the four divisions (forests, domains, organizational units, and sites) to their maximum potential. Remember that it is not necessary to create separate domains to divide administrative privileges. Within Active Directory, it is possible to delegate administrative privileges based on organizational units.

Flexible Single Master Operation Roles

Active Directory supports multi-master replication of the directory data store between all domain controllers (DC’s) in the domain, so all domain controllers in a domain are essentially peers. However, some changes are impractical to perform in using multi-master replication, so, for each of these types of changes, one domain controller, called the operations master, accepts requests for such changes.

In every forest, there are at least five operations master roles that are assigned to one or more domain controllers. Forest-wide operations master roles must appear only once in every forest. Domain-wide operations master roles must appear once in every domain in the forest.

The five FSMO roles are:

  • Forest Wide Roles :
    • Schema Master:

               The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master the Schema and you should be a Schema Admin to make changes to. There can be only one schema master in the whole forest.

  • Domain naming master:

             The domain naming master domain controller controls the addition or removal of domains in the forest. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross-references to domains in external directories. There can be only one domain naming master in the whole forest.

  • Domain Wide Roles :
    • PDC Emulator :

             This role is the most heavily used of all FSMO roles and has the widest range of functions. The domain controller that holds the PDC Emulator role is the root time server for synchronizing the clocks of all Windows computers in your forest. It’s critically important that computer clocks are synchronized across your forest because if they’re out by too much then Kerberos authentication can fail and users won’t be able to log on to the network. Another function of the PDC Emulator is that it is the domain controller to which all changes to Group Policy are initially made. For example, if you create a new Group Policy Object (GPO) then this is first created in the directory database and within the SYSVOL share on the PDC Emulator, and from there the GPO is replicated to all other domain controllers in the domain. Finally, all password changes and account lockout issues are handled by the PDC Emulator to ensure that password changes are replicated properly and account lockout policy is effective. So even though the PDC Emulator emulates an NT PDC (which is why this role is called PDC Emulator), it also does a whole lot of other stuff. In fact, the PDC Emulator role is the most heavily utilized FSMO role. Finally, every domain has its own PDC Emulator role, so if you have N domains in your forest then you will have N domain controllers with the PDC Emulator role as well.

  • Infrastructure Master:

             When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object’s SID and distinguished name in a cross-domain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.

Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server (GC). A recommendation that Microsoft made a long time ago about not putting the Infrastructure Master on a Global Catalog server? Why is it so? Let’s try to understand why ..

Every domain controller is personally responsible for maintaining their own data table and how that data is internally linked. Internally, the DB on each DC may not be identical but the outcome will be the same.

On each DC, to add a user to a group, that user must physically be present in the local data table either as a user account or a phantom object.

A Global Catalog Server has a partial copy of every object in the forest in its data table. Objects from other domains don’t have all their attributes populated but nonetheless are present. Because of this, it doesn’t need phantom objects because it has the real objects locally.

A Domain Controller that isn’t a GC doesn’t have a copy of every object in the forest in its data table. It only contains objects from its own domain. Because of this, it has to create phantom objects to reference the real objects from other domains.

The infrastructure master is responsible for updating or deleting phantom objects if/when they change. For example, does the actual Dave account in the forest root still exist? Has he been moved or renamed? This process runs every 2 days and asks this question and then either updates or deletes the phantom objects accordingly.

If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold.  If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.

  • Relative ID (RID) Master:

The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.  Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC’s allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain’s RID master. The domain RID master responds to the request by retrieving RIDs from the domain’s unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.