Starting from Exchange 2010 we don’t leverage ACL anymore, we introduced RBAC (from more detail see my previous post)

Now, if we act as we used to do, meaning assign a user as a Distribution Group owner

And then try to modify the D.G membership from Outlook, this is the error you get

One more thing, by default in Exchange 2013, when you create a D.G it will be configured in a way that anyone can join it or leave it without approval

You need to change the default setting to make a Distribution Group closed or to require the owner approval.

For this blog, we’ll make the D.G closed

We need to use an existing RBAC user Role or create a new one if the build-in role has more permission than what we want to grant to the end users.

To understand what are the RBAC permissions granted to the end users by default, you need to look at the “Default Role Assignment Policy”

 As you can see, there is a RBAC role called “MyDistributionGroups” that is not added to the default policy.

To understand now what kind of things can be done with this Role, we need to run this PowerShell command

From the output we can understand that any user for which we grant this role will be able NOT ONLY to manage Distribution Groups, but also to create and remove D.Gs

In this blog we’ll focus on how to give the end users the same permissions they have when they were assigned as the D.G owner in Exchange 2003 and Exchange 2007.

For that, we need to create a custom RBAC Role that has “MyDistrbutionGroups” as parent by running this PowerShell command

We need now the customize this RBAC Role by removing the “Extra” permissions not required for the end users

1. We need to prevent them from modifying the D.Gs properties, from the PowerShell, run the Command below

1. We need to prevent them from creating new D.Gs by running the Command below

1. We need to prevent them from removing D.Gs by running the Command below

Now we need to check what are the permissions left for this RBAC custom Users Role

As you can see, when we going to add this Custom Role to the “Default Role Assignment Policy” the users that will be granted as a Distribution Group owners will only be able to manage the D.G membership.

Now we need to add this Role to the “Default Role Assignment Policy”

Doing the test again from Outlook, you see that now we can add and remove Distribution Groups members as required

Ghazi Boufaden from NEPA PFE team.

RBAC enables you to control, at both broad and granular levels, what administrators and end-users can do. RBAC also enables you to more closely align the roles you assign users and administrators to the actual roles they hold within your organization. In Exchange 2007, the server permissions model applied only to the administrators who managed the Exchange 2007 infrastructure. In Exchange 2010/2013, RBAC now controls both the administrative tasks that can be performed and the extent to which users can now administer their own mailbox and distribution groups.

In this Blog I’ll walk you through the creation of a custom Role Group “Admin1” that has to perform the tasks below

Procedure

1. Create 2 Management Roles for “Admin1” to make them:

• Mount/Dismount databases

• Update/Suspend/resume databases copies

• Check databases copies status

• Switchover/Failover databases

   

a. Create a Management Role that has the same permission as the “Database Copies” management Role with the following command

b. Remove the management Role entries that are not required for Admin1 Group with the commad below

c. Repeat STEP-B until you remove all the unnecessary commands

d. Check the entries that you left in the Management Role with the following command

Note: Make sure you left only the list shown below:

e. Create a Management Role that has the same permission as the “Databases” Management Role with the following command

f. Remove the management Role entries that are not required for Admin1 Group with the commad below 

g. Repeat Above until you remove all the unnecessary commands as shown below

2. Grant “Admin1” the "View-Only Configuration" role permissions with the command below

3. Create a management Role that has the same permission as the “Organization Configuration” Management Role with the following command

a. Remove the management Role entries that are not required for Admin1 Group with the commad below

b. Repeat above until you remove all the unnecessary commands as shown below

c. To Grant the “Admin1” Group the management role "Admin1_Organization Configuration" run the command below

4. Create a management role that has the same permission as "Message Tracking" Role with the following command

a. Remove the management Role entries that are not required for Admin1 Group with the commad below

b. To Grant the “Admin1” Group the management role "Admin1_Message Tracking" run the command below

5. Create a management role that has the same permission as "Recipient Policies" Role with the following command

a. Remove the management Role entries that are not required for Admin1 Group with the commad below:

b. Create a new RoleGroup "Admin1_Recipient Management", granted the permissions to create/manage recipients and  add “Admin1” Group as member "Admin1_Message Tracking" with the command below

6. Grant “Admin1” the ""Support Diagnostics" Role permissions with the command below

7. To Grant the “Admin1” Group the right to perform Mailbox Import Export run the command below

8. Create a management role that has the same permission as “Exchange Server Certificates" Role with the following command

a. Remove the management Role entries that are not required for Admin1 Group with the commad below

b. To Grant the “Admin1” Group the management role "Admin1_Exchange Server Certificates" run the command below

9. From the ECP, add the Management Roles “Admin1_Database_Copies” and “Admin1_Databases” to the Role Group “Admin1”

Ghazi Boufaden from NEPA PFE team.

Fazal Muhammad Khan has made an excellent series of videos showing and explaining the different features and enhancements in Active Directory on Windows Server 2012!

We continue with Part 3 : Group Managed Service Accounts

Enjoy!

All the videos:

https://blogs.technet.com/b/nepapfe/archive/2013/11/08/windows-2012-active-directory-domain-services-videos.aspx

https://blogs.technet.com/b/nepapfe/archive/2014/02/05/windows-2012-active-directory-domain-services-videos-2.aspx

Fazal Muhammad Khan from NEPA PFE team.

In Operations Manager, this is accomplished through the use of certificates issued for each computer. If there are many agent-monitored computers, this results in high administrative overhead for managing all those certificates. To reduce this administrative overhead, Operations Manager has a server role called the gateway server. Gateway servers are located within the trust boundary of the agents and can participate in the mandatory mutual authentication.

To support the mandatory secure mutual authentication between the gateway servers and the management servers, certificates must be issued and installed, but only for the gateway and management servers. This reduces the number of certificates required, and in the case of an intervening firewall it also reduces the number of authorized endpoints to be defined in the firewall rules. The following illustration shows the authentication relationships in a management group using a gateway server.

In this blog section, we will see how to install a Certificate Authority Server and How to create a template to issue Operations Manager Certificates.

All you have to do is to Add Active Directory Certificate Services role and the Certification Authority Web Enrollment.

Open the Active Directory Certificate Services and Click on Certificate Template then Right click on IPSec (offline request) and choose Duplicate Template.

Once you click on Duplicate Template the following wizard will pop up

Name your certificate template 

Ensure that Allow Private Key to be exported is ticked.

 In the Security Tab Allow Authenticated users to Enroll Certificate.

In the Extensions Tab, double click on Application Policies and remove PKI and add Client Authentication and Server Authentication. 

Then right-click on Certificate Template > New > Certificate Template To Issue.

And Select the Template that you have just created.

Now we have our Certificate Authority ready to issue certificates that will be used for the mutual Authentication.

On all machines that are not joined to Domain including the Gateway server the Root CA Certificate must be installed and added to the Trusted root Citification Authorities because these machines don’t trust the Enterprise CA installed before.

To do that, Open MMC

Add you don’t trust the Enterprise CA, and choose Certificates Snap-in

Add both My user account and Computer account

The certificate from the Root CA needs to be added in this list.

Open the web browser on the gateway server, and go to the CA Web service: https://CAserver/certsrv

Add the certsrv website to the Trusted Sites.

Since the certsrv website uses ActiveX, change the security settings of Trusted Sites so that ActiveX is allowed.

Here we need to request the CA chain

Ensure that ActiveX is enabled.

The certificate is now in the list of Trusted Root Certifications Authorities, meaning our workgroup gateway server will trust certificates issued by the Enterprise Root CA created before.

Now we need to request a certificate for our gateway server

Advanced request

Create and submit

Select the template that was created earlier, and fill in the Name and Friendly Name fields with the FQDN of your gateway server.

Since mine is in a workgroup, the NetBIOS name is sufficient.

And now the certificate is generated and we can install it

Done

When you install the certificate, it will be installed in the User store.

But since we are authenticating computer the certificate must be imported in the computer store.

So open the Certificates MMC and export the certificate from the user store and import it to the local computer store.

The certificate is now installed and you can verify if everything is installed correctly by opening the certificate and checking if the certification path is ok.

On the Management Server, we also need to install a certificate. Since we have an Enterprise Root CA, integrated with AD, the root CA certificate is already trusted by our MS that is a domain member.

Now we can start installing the agent on the non-domain machine.

Give the management group name - this can be found in the title bar of the console on the management server - and the management server name; note that you must add in the hosts file the name of the management server and its corresponding IP.

The port number can be changed if desired. By default it is 5723.Only this port needs to be open on the firewall from the non-domain agent to the Management Server.

Then we have to Export the created certificate

And import it in the Personal Store of the Computer Account and User Account.

Then copy the MOMCertImport.exe tool to the non-domain agent.

MOMCertImport.exe can be found in the SupportTools Folder

Run MOMCertImport.exe and point to the Imported Certificate

You’ll get a message that the action succeeded, and you can check progress in the Operations Manager event log.

Troubleshooting:

If you get event 21006, make sure the firewalls on the gateway and/or on the management server are not blocking communication

Don‘t forget to enable Agent Proxy for the gateway, as this one will act as a proxy for other systems connecting through the gateway server!

To check if it’s working, go to the Operations Manager Console – you should see something similar to this

Dany Abboud from NEPA PFE team.

I have noticed the following at many customers who had upgraded their Active Directory from Windows 2000/2003 to 2008 and plus: they do not (or forget to) upgrade Sysvol from FRS to DFSR!

Several Technet articles covered the steps to do for Sysvol migration, so there is no need to go in details here…

“Upgrading to DFSR? What is DFSR? Besides, everything is working fine! Why should I upgrade?”

Those are –very often- the questions and feedbacks I get from customers :)

So here is the thing:

• Keep in mind that Sysvol is a shared folder (with DFS name space) that needs to be the same copy on each DC,
• Sysvol is replicated through DCs using File Replication Service (FRS) or Distributed File System Replication (DFS-R),
• This replication follows the Active Directory replication topology and paths,
• We have stopped any development on FRS since 2003, which means for example: no updates or hotfixes! On the other side, DFSR is here to stay for a long time (cross-fingers!)
• FRS is not a bandwidth optimization service, but DFSR is! For example, DFSR replicates partial file changes / efficient compression / self-healing mechanism for database corruption or journal wraps …etc (see the comparison here)
• DFSR requires Domain Functional Level –DFL for short- of minimum Windows 2008 (how to check and upgrade your DFL here), so you have to review the upgrade possibility in your environment,

All right! I’m planning to do it, what are the actions?

That’s good! Here are the summarized actions for upgrading your Sysvol to DFS-R:

1. Migrating to the “Prepared state” : FRS is still being used for replication, and DFS-R will hold a copy of your Sysvol data,
2. Migrating to the “Redirected state” : DFSR-R will be used for replication the ‘copy’ Sysvol, and answering new requests, but FRS is still replicating the ‘old’ Sysvol folder,
3. Migrating to the “Eliminated state” : no more FRS, only DFS-R is being used for Sysvol replication  

Side notes:

• Required firewall ports for DFS-R here
• Troubleshooting DFSR upgrades here
• More info on TechNet  

Hope it’s simple now!

Imed Boukhaf from NEPA team.

1.2 In the EAC, go to Servers > Databases.
1.2 Select the mailbox database whose copy you want to remove.
1.3 In the Details pane, locate the passive copy you want to remove and click Remove.
1.4 Confirm the removal on the warning dialog box by clicking yes.
1.5 Click ok to confirm the removal after reviewing any messages.
1.6 After all copies are removed, preserve the database and transaction log files from each server from which the database copy is being removed by moving them to another location. These files are being preserved so the database copies don't require re-seeding after they have been re-added.

2. Move the mailbox database path to the new location.

2.1 In the console tree, navigate to Organization Configuration > Mailbox.
2.2 In the result pane, on the Database Management tab, select the database you want to configure.
2.3 In the work pane, click Move Database Path

2.4 In the Move Database Path wizard, under Database paths, click Move to move the database path to the default location. You can change the location for the database file path by editing the Database file path field. You can change the location for the log folder path by editing the Log folder path text field.

2.5 View the status of the move operation. The wizard moves the database file path and the log folder path to the new location. Click Back to make configuration changes.
2.6 On the Completion page, confirm whether the move process completed successfully. A status of Completed indicates that the wizard completed the task successfully. A status of Failed indicates that the task wasn't completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes.
2.7 Click Finish to complete the Move Database Path wizard.
2.8 Create the necessary folder structure on each Mailbox server that previously contained a passive copy of the moved mailbox database. For example, if you moved the database to C:\mountpoints\DB1, you must create this same path on each Mailbox server that will host a mailbox database copy.
2.9 After creating the folder structure, move the passive copy of the mailbox database and its log stream to the new location. These are the files that were left from and preserved after Step 3. Repeat this process for each database copy that was removed in Step 1-6.

Othman Benkirane from NEPA PFE team.

My SCOM is running on the top of Windows 2008 R2 SP1 and SQL 2008 R2 SP2 and of course has SCOM 2012 SP1 with CU4 installed.
First reboot the machine to be sure that there is no issue. Once everything is up and running, we can proceed with the installation.
Download the SCOM 2012 R2 ISO file and mount it to the machine.

Prerequisites:

• Microsoft System CLR types for SQL Server 2012.
• Microsoft Report Viewer 2012 Runtime.

You must restart the system before proceeding with the report viewer installation 

Now we proceed with the Microsoft Report Viewer 2012 installation:

Ensure that your current Operating system is fully updated.
Let’s start with the in place upgrade.Please insert the System Center Operations Manager R2 Media.

Note that all roles are combined on one machine.

Click on Install

So as we can see, the wizard found the installed roles and will check the prerequisites for that upgrade.

Quick Tip:Before doing any upgrade , ensure that both databases are backed up (OperationsManager , and OperationsManagerDW).

Now it asks you to agree with the license terms.

Select installation location. In my case the default installation location is fine, so I will click Next.

A prerequisite checker starts running which verifies the hardware and software configuration.

Passed! Next!

As we can see, you have the choice of Local System or domain account. If the database is running locally as it’s the case you can leave it at Local System.

If the databases are on remote server it requires to use a domain account.

We are ready to upgrade Click  Button.

It will take a while for the upgrade to finalize, there is a progress bar for each role.

During the Operational Database Configuration phase it also imports a whole set of management packs that takes some time.

After upgrade finishes, just close the setup screen.

You will find a warning that indicates the current version of the product is not licensed, please start the Operations Manager Shell and use the Set-SCOMLicense cmdlet to license the product.

Start the SCOM console and go to Help -> About.

Next we have to update the SCOM agents.
Go to the Administration Pane of the SCOM console and open the Pending Management node, you will see all the agents that needs update, just approve them.

All the agents that are installed through the SCOM console are manageable and set to Pending Management with the note Agent Requires Update. Right-click on them and select Approve. Use the default action account or a domain account you provide and select Upgrade.

Next jump over to the Monitoring Pane, and on the left hand side go to Operations Manager -> Agent Details -> Agents by Version.

You will see that the agents are upgraded and its version is 7.1.10184.0 this value refer to 2012 R2.

In my Next Blog, I will demonstrate how to monitor non-domain servers.

Dany Abboud From NEPA PFE Team.

Exchange 2007 single copy cluster provides high availability for the node failure scenarios and can be implemented with at least two nodes in Active/Passive model. This is very much similar to the Exchange 2003 cluster setup where shared storage is used between the nodes and storage group resides on that shared storage.

I have been to couple of customers where there were complains cluster of shifting and dismounting of the databases. I have started checking and found that resources dependency model on those Exchange 2007 clusters were not configured as per the recommendations.  Resource dependency model in Exchange 2007 Single copy clusters were implemented like exchange 2003 conventional cluster although it is changed in Exchange 2007 single copy clusters.

I have found that for both of the customers were not having physical disk resources in the dependency for the Exchange 2007 database instances. I have also found that for one of the customer “Affect the group” option for the Microsoft Exchange information store resource were not set to its default value and it was enabled.

Correcting and comparing the whole resource dependency model for Exchange 2007 Single copy cluster according to the best practices alleviated many pains to the customers and helped them to avoid critical situations.

Following articles could be used for further details and comparisons against the recommended configurations.

https://technet.microsoft.com/en-us/library/aa998607(v=exchg.80).aspx
https://technet.microsoft.com/en-us/library/aa997195(v=exchg.80).aspx

Configuring Disk Dependencies

https://technet.microsoft.com/en-us/library/bb691095(v=exchg.80).aspx

Farooq Ahmed from NEPA team.

Fazal Muhammad Khan has made an excellent series of videos showing and explaining the different features and enhancements in Active Directory on Windows Server 2012!

We start with Part 1 and 2 

Enjoy!

Part 1 (direct link)

Part 2 (direct link)

All the videos:

https://blogs.technet.com/b/nepapfe/archive/2013/11/08/windows-2012-active-directory-domain-services-videos.aspx

https://blogs.technet.com/b/nepapfe/archive/2014/02/05/windows-2012-active-directory-domain-services-videos-2.aspx

Fazal Muhammad Khan from NEPA PFE team.

In some cases when Managed Availability perform an action to recover from an error you may need to know which health metrics “Probe” Managed Availability used to decide that Exchange component or server needs a fix.

Why you need to know that? Because you may need to stop a behavior like “system reboot” when an error occurred, you may find in some situations that it’s better to know the root cause and fix this problem by yourself instead of automatically let Managed Availability fix it.

Managed Availability

First lets overview what are the main components of Managed Availably:

• Probe engine:  The Probe Engine takes measurements on the server.
• Monitoring probe engine:  The Monitoring Probe Engine stores the business logic about what constitutes a healthy state. It functions like a pattern recognition engine, looking for patterns and measurements that differ from a healthy state, and then evaluating whether a component or feature is unhealthy.
• Responder engine:  When the Responder Engine is alerted about an unhealthy component, its first action is to try to recover that component. Managed availability enables multi-stage recovery actions. The first attempt may be to restart the application pool, the second attempt may be to restart the corresponding service, and the third attempt may be to restart the server. And, the final attempt may be to put the server offline, so that it no longer accepts traffic. If all of these actions fail, an alert is sent to the help desk.

All above are controlled by the Exchange Health Manager Service (MSExchangeHMHost.exe) and the Exchange Health Manager Worker process (MSExchangeHMWorker.exe)

The relationship between these components is like

Probes (monitor and when fails occur) --> Monitor status change --> Responder takes action

So to find the root cause and why a responder invoked a specific actions we will go in the reverse way

Responder takes action --> which monitor? --> Find the failing probe.

For Example: Use the following command to get all windows events for responder that forced your server to reboot.

The output will be like this:

In this case, the bug check was initiated by the ActiveDirectoryConnectivityConfigDCServerReboot

Now let’s get more details about this Responder

The AlertMask show which Probe used by the ActiveDirectoryConnectivityConfigDCServerReboot Responder.

A repetitive failed probe causes a Monitor change and a recovery action is invoked.  The details of the failing Probe is going to provide information about the exact failure.

Now we need to dig inside the Windows Events to get a Failed probe and check the error message associated with.

The Result may show you an error like

<Error>Received a referral to contoso.com when requesting DC=contoso,DC=com from dc1.child.contoso.com.  You have specified the wrong server for this operation. Filter = (&amp;(objectClass=\2a)(!(msExchCU=*))).</Error> 

Now what! Now You know why this Probe failed and made a corresponding responder to restart your server .what you can do now is to stop this responder till you fix this issue if it going to take much time .

This Responder is temporary disabled by adding a GlobalMonitoringOverride

Important: The main focus should be to analyze and resolve the main issue that is causing the Probe failure.  If you decide to disable the responder, be aware that you are preventing Exchange from taking automated recovery actions for any monitors that call this responder.  The Responder should be disabled only if the Responder’s actions are causing serious outages and fixing the main issue is going to take a significant amount of time. 

Later you can enable this Responder by removing the GlobalMonitoringOverride

Mohamed Dawy from PFE Egypt team.