Browsed by
Month: September 2015

Add a Consolidator Condition to a SCOM Monitor

Add a Consolidator Condition to a SCOM Monitor

In a lot of default SCOM management packs provided by Microsoft, we can found 2-state or 3-state monitor without consolidator. This means that as soon as the state detection condition (based on a script for example) executed at a regular interval no longer fulfills the criteria, the associated monitor goes directly into a warning or critical condition and generally create an alert. But mostly, this is only a temporary status that corresponds to side effects resulting from other network services, and it’s not relevant for monitoring administrators to see these alerts in SCOM console or even receive notifications about it.

The simplest way to find if a monitor includes a consolidator mechanism is to look at monitor’s overridable parameters directly in SCOM console. If you can’t see “number of samples” parameter either in configuration or override tab, it means that monitor is not using consolidator mechanism.

If you need to work with some monitors based on default management pack provided by Microsoft without consolidator mechanism, you will have to create management pack(s) containing improved monitors and associated overrides. In this article, I will create a management pack containing improved monitor for SYSVOL share health monitoring on Active Directory Domain Controller and associated override. To achieve this I will use Visual Studio 2013 and VSAE extension available here.

The first thing to do is to find management pack that contains monitor to improve by going to its properties and looks at parent management pack.

Then you need to list management pack dependencies that you will have to reference in your custom management pack. You can find management pack dependencies by going to Administrator pane, then Management Packs and research for the MP we find previously. In dependencies tab of the properties window, you will have the full list of dependencies.

You need to get MP files for each of listed management packs as your custom management pack will use them as dependencies too. You can find default management packs in setup source files and download the others from Microsoft catalog. Then you will need to create a new project in Visual Studio depending on your version of SCOM.

You will add all dependencies management pack files and the management pack to improve.

Then you will need to create an empty management pack fragment that will contain improved monitor.

Next step will be to construct your monitor based on the existing one. The easiest way to accomplish this is to copy all parts (data source, monitor type, monitor, string resource and language pack) of the monitor to improve in an empty fragment.

Then you need to change unique ID of each object. For example, you can change data source ID from Microsoft.Windows.Server.2008.AD.EssentialService.SysVol.DataSource to Microsoft.Windows.Server.2008.AD.EssentialService.SysVolUpdated.DataSource.

You also need to update targets to your references alias or update your references alias to match existing target (preferred solution).

Then you will update monitor type by adding consolidator section.

You need to disable old monitor using override. In order to do this, you have to add a monitor property override into overrides section.

Finally, you can build management pack and import it into your SCOM environment.

After a few minutes, you can verify that your monitor is working properly and that the former is disabled. You can retrieve full visual studio project here or management pack XML here.

Error: Repair a Suspect MSSQL Database

Error: Repair a Suspect MSSQL Database

If you have your MSSQL database that is tagged as suspect and you are unable to connect to it, you will need to launch a query to check the database integrity. Remember that your MSSQL consider a database as suspect for these reasons :

  • The database could have become corrupted.
  • There is not enough space available for the SQL Server to recover the database during startup.
  • The database cannot be opened due to inaccessible files or insufficient memory or disk space.
  • The database files are being held by operating system, third party backup software etc.
  • There was an unexpected SQL Server Shutdown, power failure or a hardware failure.

To resolve this issue, you need to launch this SQL query into SQL Management Studio. Be sure to have a full backup of your database and to stop any services that try to connect to this database.

This recovery process will take awhile depending on your database size and computing performance of your server.

At the end of the query your database should no longer be tagged as suspect and you should be able to access it.

Deployment of Microsoft Intune – Part 4

Deployment of Microsoft Intune – Part 4

In the previous part of the series, we saw how to grant your users the rights to connect to Intune platform, to enroll their mobile devices, and to create configuration policies. Here we will see how to implement automatic deployment of company portal application during device enrollment and to configure custom OMA-URI settings for WP 8.1 devices.

In order to implement automatic deployment of company portal application during WP 8.1 device enrollment, we will use Support tool for Windows Intune trial management of window phone provided by Microsoft. Once you have downloaded and installed package, you can retrieve SSP.xap file which corresponds to Company Portal application.

The next step is to upload and register this application as Company Portal application in Microsoft Intune console.

Then when you enroll a WP 8.1 device like we saw in previous part of this series, it will ask if we want to automatically install Company Portal application.

But if have you deployed a configuration policy that allows devices to only listed applications, you will need to add an exception for this company portal application.

To add an application in this allow list, you need to add the windows store URL dedicated to the application. But in this case, company portal application include in the support tool package is not the same as the company portal app available on windows store. So to allow this application on your WP 8.1 mobile devices, you need to get the product id in the manifest file of the application. To access this file you need to uncompress SSP.xap file and locate WMAppManifext.xml. Then you need to open this file with your editor and to copy ProductID, in this case, the ID is 01914a77-09e7-4f01-88d1-099162777f9b.

Then you need to add an old URL for windows phone store built with product id ( in the allowed apps list to use company portal application on mobile devices.

If you use custom configuration policy based on OMA-URI, you can authorize company portal app on mobile devices by adding this rule.

Remind that you can retrieve the list of OMA-URI settings and parameters in Windows Phone 8.1 MDM Protocol documentation.

Error: SCOM Delta Synchronization Engine Failed to Execute (Event ID 29181)

Error: SCOM Delta Synchronization Engine Failed to Execute (Event ID 29181)

In the event viewer of your management server, if you see recursive error with Event ID 29181 with exception Data access operation failed, it means that Delta Synchronization engine work item failed to execute due to incorrect configuration of SQL Compatibility Level.

To fix this error, you have to change SQL Compatibility Level to SQL 2008(100) or newer of your Operations Manager database in SQL Management Studio.

Error: WinRM issue during SCOM Agent Installation on a Linux Machine

Error: WinRM issue during SCOM Agent Installation on a Linux Machine

During agent deployment on Linux machine from SCOM console, if you encounter this WinRM error: The WinRM client received an HTTP status code of 501 from the remote WS-Management service.

To fix the problem you have to uninstall KB2585542 on all management servers.

And you also have to add this registry key on all management servers.

You will be able to install SCOM Agent on Linux Machine without rebooting anything.
Deployment of Microsoft Intune – Part 3

Deployment of Microsoft Intune – Part 3

In the previous part of the series, we saw how to grant your users the rights to connect to Intune platform and more important to enroll their mobile devices. Here we will see how to configure settings and to manage applications through Microsoft Intune policies (only WP 8.1 devices on this part).

Considering that devices are managed by Microsoft Intune, we have to create specific policies for general settings, email configuration, certificate profiles, application management, etc. The creation of these policies could also be made before enrollment of devices.

To create these policies, you have to connect to your Microsoft Intune admin console ( and go to Policy section.

Then you have to click on add, and chose the type of policy you want to create. We first create a general configuration policy (for WP 8.1 and later) to configure general settings.

Then, you can either wait for devices to run through their cycle update process or you can force compliance check on the device. Once the policy is loaded on the device, you can verify that all is correctly applied.

Now we need to create a policy to give users access to their corporate mailbox. In order to accomplish this, we will create an Email Profile. In this case, mailboxes are hosted on Office 365.

Once the policy is created, you have to deploy it to a group of users and not devices. After compliance update check, you will see the creation of configured mailbox on devices automatically configured with your parameters.

If you need to deploy additional specific parameters, you can create a custom policy based on OMA-URI settings described in Windows Phone 8.1 MDM protocol in this case. Moreover, several customers asked me to delete the possibility to unenroll devices from Workplace settings like we can see below.

In order to accomplish this, you have to study Windows Phone 8.1 MDM protocol documentation and find the parameter that corresponds to your need. In this case, the parameter that will be used is:

And now when your user wants to delete the device from Intune management, he will receive this message.

Finally, we will see how to deploy apps to Windows Phone 8.1 devices with Intune (I will not handle Trusted Certificate, SCEP Certificate, VPN and Wi-Fi profiles in this article). You have two options for deployment of apps on WP 8.1 devices, you can either install a Windows Phone app package, an external link to WP application in Windows Store or an external link to a website (like internal CRM for example). In this case, we will just create an external link to Twitter.

Once the app is created you have to deploy it. As it is External Link to Windows Phone Store, you cannot deploy it as required. If you want to manage an app as required, you have to download the XAP/APPX file and create a Windows Phone app package installer. I will show you in another article how to get the .appx file from Windows Store, in order to deploy it as mandatory on your devices.

Once the configuration is done on Microsoft Intune portal, users will retrieve the application as available in enterprise store application on devices.

In the next part, we will see how to implement automatic deployment of company portal application during device enrollment and to configure custom OMA-URI settings for WP 8.1 devices (Implementation of Microsoft Intune – Part 4).

Deployment of Microsoft Intune – Part 2

Deployment of Microsoft Intune – Part 2

In the first part of this series, we saw how to create a Microsoft Intune tenant and how to synchronize your local Active Directory to it. Now we have to grant users right to connect to this platform and more important to enroll their mobile devices (only WP 8.1 devices on this part).

In order to do this, you have to go back to your Account portal (

Then you need to edit the properties of selected users and add them to Microsoft Intune user group.

Then you have to wait for the update process to complete (between 2 and 60 minutes). You know it’s done when you can see your users in the admin console (

Like in Configuration Manager with a collection, you have to work with groups in Intune. It will permit to apply all kind of configuration directly to a group of users or devices. Let’s see how to create a standard dynamic group with all our end users.

Then you have to set mobile device management authority. This is an important choice and you cannot change it later without the help of Microsoft support. You can either choose Microsoft Intune or SCCM 2012 R2 as mobile device management authority. In our case, we will set it to Microsoft Intune.

When it’s done you can now enable and configure additional features to enroll mobile devices. In this part, we will only focus on Windows Phone 8.1.

To simplify enrollment of mobile devices by users, you need to add two CNAME records to your public domain name.

At this time you can enroll Windows Phone 8.1 devices. We will see how to configure policies just after adding a device. The device used has been reset to factory settings and no Microsoft account has been configured. In order to add the device, you need to open settings pane.

Then go to Workplace configuration pane and sign-in with your company account.

Once your device is enrolled to your Microsoft Intune tenant you can retrieve it directly in the admin portal.

In the next part, we will see how to configure specific settings on Windows Phone devices through policies (Implementation of Microsoft Intune – Part 3).

Deployment of Microsoft Intune – Part 1

Deployment of Microsoft Intune – Part 1

The goal of this series will be to implement and configure Microsoft Intune as MDM (Mobile Device Management) solution for mobile devices (Android, iOS and Windows Phone) and PC.

In order to configure and use Microsoft Intune (or other Microsoft Cloud services like Office 365), you need first to synchronize your on-premises Active Directory with Azure Active Directory. To accomplish this, you have to create a Microsoft Intune account (trial in our case) directly on this web page.
You have to choose a domain name that must be unique and a domain account linked to this new Azure AD domain.

Once connected to your account portal, you will need to add your public domain name that will be used as UPN suffix.

Once your public domain is verified in the Microsoft Intune console, you will have to add the UPN suffix in your local Active Directory. To do this, just connect to a domain controller, right-click and choose Properties on Active Directory Domains and Trusts MMC.

Once UPN suffix is added, you will now need to change user login name of your users. You can do it manually but personally, I prefer to use this little tool called ADModify that will permit to manage that change much more easily.

Now you have your local and your cloud environment that is ready to be synchronized. To accomplish this, you have to download Microsoft Azure Active Directory Connect (download here). If you need more information about Azure AD Connect you can refer to my previous article. The configuration of AADC tool, the creation of our Intune trial account and the synchronization will be covered in this first part.

You need to install the synchronization tool on a Windows Server on your LAN with Internet connectivity (try to avoid DC).

This will be a fresh installation of the tool, but if you have DirSync installed you can use the same tool to upgrade it. You have the choice between using express settings (automatic creation of service account, groups, database, etc.) or customizing required components.

In our case, we will not use express settings to handle customization of some component like service account used to synchronize your on-premises AD with Microsoft Azure AD. The service account must be an Enterprise Administrator account for your local Active Directory.

Then, following your needs you have to choose User sign-in method. In our case, we will prefer Password Synchronization. If you need more details about this part, you can refer to my previous article.

This window will permit to synchronize your local Active Directory forest(s) to a single Azure Active Directory tenant.

In order to avoid duplicate records for the same user inside your Azure Active Directory, if you synchronize several forests for example. This screen can create a rule to identify and regroup them under a single object.

Here you have to choice to synchronize only a group of users. As we use this tool in a lab environment, I will specify to only synchronize my future Intune users.

Finally, we can choose to enable optional features. Some of the features are grayed out because they need prerequisites or additional configuration. For the moment, we will only active Password Writeback feature that is used to synchronize in both ways password of the user.

Make sure to export and backup the keys used to encrypt data in Azure ADSync to a file.

Finally, you can check that synchronization is occurring through the Synchronization Service Manager.

Back to your account portal, you can see users/groups that have been synchronized (logo) and when the last synchronization occurred.

In part 2, we will see how to configure Intune in order to enroll, customize and secure Windows Phone 8.1 devices.

Azure Active Directory Synchronization

Azure Active Directory Synchronization

In the case you need to work with Microsoft Cloud services like Office 365, Intune, Azure, you will have to synchronize your on-premises Active Directory objects (users, contacts, and groups) to Microsoft cloud services (Azure Active Directory). In order to accomplish this, you will have to choose between Same Sign On or Single Sign On.

  • Same Sign-On, will use synchronization tools (DirSync, AADSync and FIM) to synchronize your on-premises Active Directory objects and their associated password (requires Password Sync). It means that authentication requests and access rights will only be handled by Azure Active Directory without contacting your on-premises domain controllers.
  • Single Sign On, will also use synchronization tools but authentication requests and access right will be redirected to your on-premises AD FS infrastructure connected to local Active Directory. This scenario will be used if your organization requires SSO, MFA and other features. In addition, in term of infrastructure, you will need to implement high availability AD FS service on your DMZ with redundant links to avoid service interruption.

Since the beginning of Microsoft Azure services, we have to use DirSync to accomplish this synchronization (without Password Sync), and when Microsoft released a bunch of new tools to improve this process that bring a lot of confusion…

But rejoice yourself because there is a new product called Azure Active Directory Connect that replaces AADSync and DirSync. Azure AD Connect incorporates the components and functionality previously released as DirSync and AADSync. At some point in the future, support for DirSync and AADSync will end. Moreover, Azure Active Directory Sync will allow you to do the following:

  • Synchronize multi-forest Active Directory environments without needing the complete feature set of Forefront Identity Manager 2012 R2
  • Advanced provisioning, mapping and filtering rules for objects and attributes, including support for syncing and a very minimal set of user attributes (only 7)
  • Configuring multiple on-premises Exchange organizations to map to a single Active Directory tenant

You can download the tool here and find more information here.