Posted on:
Categories: System Center;Azure
Description: The latest version of System Center Endpoint protection ( - March 8, 2016) has a bug in the included Powershell Module MpProvider.psd1 located in the default directory of C:\Program Files\Microsoft Security Client\MpProvider. This causes information for Operational Insights to be reported
The latest version of System Center Endpoint protection ( - March 8, 2016) has a bug in the included PowerShell Module MpProvider.psd1 located in the default directory of C\Program Files\Microsoft Security Client\MpProvider. The bug is currently a reference to a nested module that doesn't exist, if you attempt to import this module, you'll see the following. The reason this is so important, is that the Antimalware Intelligence Pack that comes down from the "Malware Assessment" solution in Operational Insights, requires access to this module in order to gather status information regarding signature dates, definitions, malware activity, etc. You can view the code that's run on any Operational Insight agents (or SCOM connected agents) that have the Antimalware Assessment solution configured here. http// How this script works is by attempting to import the required module "MpProvider.psd1" to gather information regarding the status of SCEP. If the import was successful, the script will continue to run gathering information about SCEP. However, if the module fails to import, the script will fall back to gathering information about the "Malicious Software & Removal Tool". You can see this in the Operations Manager event viewer (Event ID's 9991-9993). These events will show the information that's gathered by the Malware Status collection scripts, which is also the actual information that's transmitted up to Operational Insights. The quickest fix for this bug is to simply modify the MpProvider.psd1 module and remove the portion highlighted in the top screenshot of this article 'MSFT_MpWDOScan.cdxml'. The reference to this cdXML does not existing in the "C\Program Files\Microsoft Security Client\MpProvider" folder on any client I've checked. You could push this updated module file out to affected clients using Group Policy Preferences, or simply wait for a fix from Microsoft (no ETA). Or, better yet Microsoft provided me with the missing module that you could deploy to the directory in question (attached at the bottom), both fixes will work. If we modify the module, then wait for the collection cycle to re-run (default hourly), you'll NOW see in the Event Log that proper SCEP information is gathered. This information will flow up to Operational Insights and can be seen by querying for "ProtectionStatusRank = 150". It may take some time depending on your data retention for the old "Not Protected" client information to age out and be removed from Operational Insights before everything reports correctly. Also, note that "Behavior Monitoring" in SCEP MUST be Enabled in your SCEP policies for Operational Insights to properly report healthy, protected SCEP clients. MSFT_MpWDOScan.cdxml

Posted on:
Categories: Office 365;SharePoint
Description: This blog posts explains how to validate a field in SharePoint by using Client-side validation and JS Link
Client-side rendering (CSR) has been introduced by Microsoft with SharePoint 2013 and Office 365. With CSR you can add additional functionality to some SharePoint elements very easily by just adding a JavaScript file which implements the missing functionality. There is neither an explicit deployment process nor any WSP deployment! When looking at fields in SharePoint lists and libraries, CSR can be used to change the way fields and their values are rendered. A common example is to render a project status not to be displayed as a percentage value, but as a coloured status indicator. But there is much more that can be done with CSR. An additional example is to add custom validation code to fields in a SharePoint list. Although fields already provide a few basic validators (like the 'required' validator or some number field validators), sometimes additional validators are needed. In this blog post I want to explain how to implement a basic CSR validator. For my example I'm using a field which should hold Canadian ZIP codes. CSR basically works like this instead of SharePoint rendering a field, the rendering is done by custom JavaScript code. The basic idea in terms of validators is this if the rendering is done by custom JavaScript code, this code can perform a validation as well. Let's have a look at the code In my example I created a basic generic list (called CSR Validation) with an additional field called MyField which is of type Text and should hold Canadian ZIP codes (as an example). First a code section is needed to define in what forms of a list or a library the validation should be used. In my example the validation should be added to the NewForm and the EditForm as both forms allow for entering or editing data. (function () //Define field and forms that should be used var myFieldCtx = ; myFieldCtx.Templates = ; myFieldCtx.Templates.Fields = "MyField" "NewForm"MyFieldTemplate, "EditForm"MyFieldTemplate ; SPClientTemplates.TemplateManager.RegisterTemplateOverrides(myFieldCtx); )(); The following code snippet handles the custom rendering. Currently it just returns the HTML code for rendering the MyField text field and the additional error message placeholder. I will add the validator initialization later – that's what the ToDo comment will be used for. // This function provides the rendering logic function MyFieldTemplate(ctx) var formCtx = SPClientTemplates.Utility.GetFormContextForCurrentField(ctx); // ToDo Link validation to field between these lines // -------------------------------------------------- // -------------------------------------------------- // ToDo Link validation to field between these lines // Perform the custom field rendering var htmlString1 = "<span dir='none'>"; var htmlString2 = "<input type='text' value='" + formCtx.fieldValue + "' maxlength='7' id='MyField' class='ms-long'><br>"; var htmlString3 = "<span id='myFieldValidationError' class='ms-formvalidation ms-csrformvalidation'>"; var htmlString4 = "</span></span>"; return htmlString1.concat(htmlString2, htmlString3, htmlString4); Let's first check if the custom rendering is working as expected. I add the above code to a new text file, name it MyFieldValidation.js and save it to the Style Library. After I have checked in the file, I need to remember its URL, because it is needed in the next step. Next I navigate to the list and open the NewForm. I turn the NewForm page into edit mode, open the web part properties and paste the URL (best practice is to use tokens like ~sitecollection) of my JavaScript file into the JS Link field in the webpart properties. To have the validation in the EditForm too I need to repeat these steps for the EditForm. The following screenshot shows where to find the JS Link field in the webpart properties The field in both forms should now be rendered as expected. Now I'm going to add additional validation code. To do so I simply append the following snippet to the existing code // Custom validation object to validate the field MyFieldValidator = function() MyFieldValidator.prototype.Validate = function (value) var errorOccurred = false; var errorMessage = ""; // Canadian ZIP code format Regex expression var zipRegex = new RegExp("[ABCEGHJKLMNPRSTVXY]\\d[A-Z] \\d[A-Z]\\d"); if (!zipRegex.test(value)) errorOccurred = true; errorMessage = "Invalid ZIP code"; //Send error message to error callback function return new SPClientForms.ClientValidation.ValidationResult(errorOccurred, errorMessage); ; ; // Add error message to myFieldValidationError element below the input field element function MyFieldValidationError(error) document.getElementById("myFieldValidationError").innerHTML = "<span role='alert'>" + error.errorMessage + "</span>"; The above code snippet provides the function which performs the validation based on a RegEx expression. In addition it also provides the function (called MyFieldValidationError) which displays an error message if the validation fails. To finish this example I need to register the validator function and its callback function and I need to link the validator to the text field. To do that, the following code snippet needs to be added between the two ToDo comments // ToDo Link validation to field between these lines // -------------------------------------------------- // Register a callback just before submit. formCtx.registerGetValueCallback(formCtx.fieldName, function() return document.getElementById("MyField").value; ); // Create container which is handling the new validator var validators = new SPClientForms.ClientValidation.ValidatorSet(); validators.RegisterValidator(new MyFieldValidator()); // This handler is called if the validation fails formCtx.registerValidationErrorCallback(formCtx.fieldName, MyFieldValidationError); // Link the validator with the field formCtx.registerClientValidator(formCtx.fieldName, validators); // -------------------------------------------------- // ToDo Link validation to field between these lines That's all the code needed for my example. I save it and I also clear the browser cache! Let's see if the validation works as expected. First I enter a wrong ZIP code and the validator shows the expected error message when clicking on the Save button. Now I enter a correct Canadian ZIP code and the validator does not display an error message. The new item is added to the list. I think the main advantages of CSR and CSR validation are that CSR can be done with common JavaScript code and that CSR does not need any kind of deployment process (like common SharePoint solutions). CSR is a very flexible and versatile functionality and it is perfect for customizing the UI in SharePoint and Office 365. There is one disadvantage you should keep in mind this validation will only check data that gets entered through the user interface. If data is entered by code via APIs, this kind of validation will not be able to check the data. You can download the demo script here.

Posted on:
Categories: Skype for Business
Over the recent months, you may have heard a lot of hype around Office 365 E5 plans, Cloud PBX and PSTN Conferencing however it can be confusing as to what is actually available right now and what there will be in the near future. Office 365 E5 The E5 plan is the successor of the original E4 plan and is the top of the line package that includes (but not limited to); Full Office 2016 SuiteExchange OnlineSkype for Business OnlinePSTN ConferencingCloud PBXPower BI ProDelve Analytics And much more! - all for roughly $44.20CAD per user per month Full feature list can be found on https// E4 is still currently available and if you currently have E4 this will continue on indefinitely, however this will not be available for purchase from June 2016. Cloud PBX One of the new features within the E5 plan is Cloud PBX. This is great as it means you can run your full enterprise voice features and call control on the Microsoft Office 365 stack, meaning you don't need to worry about hardware and maintenance anymore.​ For companies in the US, you can completely run your PBX in the cloud with no on-premises servers required. Users can have their own local direct dial numbers and you can even port your existing numbers from your current provider to Microsoft. For all other countries worldwide, you can still have all of your users and call control features hosted in Office 365, you just require at minimum a single mediation server on-premises to connect to either your SIP trunk or PRI gateway. Microsoft are providing a new Skype for Business instance called the Cloud Connector Edition which is completely free with your E5 licenses. The plan is for more countries to be available for the full Cloud PBX features like in the US, however timelines are unknown at the moment but rumoured to be late 2016 for Canada. PSTN Conferencing One of the other great features released is PSTN Conferencing, this allows you to host Skype for Business Online meetings and allow participants to dial-in via the PSTN. Unlike other providers such as WebEx and GoToMeeting, you do not pay per minute for every caller that dials in, you simply pay your monthly subscription cost and that is it. These numbers are available in a number of countries at the moment, with Microsoft planning to rapidly expand to as many as possible over the next year. This may be the perfect gateway for migrating your telephony to the cloud as you can start with PSTN conferencing for now and then start to migrate your existing PBX. There are many options of what can be done and Softlanding can provide a comprehensive roadmap on moving your PBX, whether it is already an on-premises Skype for Business deployment or a Cisco, Avaya or something else to the cloud. If you require any more information about any of this, please feel free to email me at