Innovation is in the air this spring (or fall for our friends in the Southern Hemisphere). I’m pleased to highlight some new capabilities we’re bringing to Intune this month. We’re adding features that increase secure productivity. Read on to learn what’s new and notable this month, then put these features to work for your organization.

Getting down to business

We have three major enhancements to highlight this month that help users get down to business:

Platform single sign-on (SSO) has arrived for macOS device enrollment: This capability helps users with macOS devices get to work faster, with a single sign in and password for their device and apps. Additionally, it enables users to automatically sign in to their Microsoft 365 productivity apps. To learn more, see this article about the rest of the Mac management news.

Windows Autopilot device preparation: Built from the ground-up with an improved architecture, this new Windows Autopilot option offers faster and more configurable self-deployment capabilities. The original, existing Windows Autopilot architecture is still in place and its existing capabilities are all still available to admins. Read more about the new and improved Windows Autopilot.

Enhanced frontline worker (FLW) device management: New capabilities make FLW devices easier to use and manage. One of the biggest improvements is updates to the Managed Home Screen. Get the whole story in this blog post.

More secure and more efficient

We’re also introducing capabilities to Intune focused on making it easier to improve security and efficiency.

New security baseline

First is an update to the Microsoft Defender for Endpoint security baseline. Security baselines are one-click collections of policies that can be applied to devices (and device groups) in Intune. This latest update is a super-efficient way to apply configurations recommended by the Microsoft Defender for Endpoint team. It’s also based on the Windows unified settings platform, which brings some additional benefits like:

Quicker turnaround for updates.
Improved reporting, including per-setting status reports.
Assignment filter support.
Improved UI.
Consistent names across Intune.

We recommend updating baselines to the latest version by selecting the check box for test baseline when they’re released:

BitLocker recovery key

The second addition is to the BitLocker recovery key workflow. Traditionally, if a user gets locked out of their BitLocker-encrypted device, they call the Help Desk. With the capability we’re rolling out, end users can access their BitLocker recovery key directly from the Company Portal web site, providing a more intuitive and streamlined path to recovery, reducing the burden on support teams.

Admins can disable this feature for users without admin rights and access to logs. For more information, see the documentation on Get recovery key for Windows.

Corporate identifiers

The third capability is an update to the Windows corporate identifiers feature. This can be used as part of any Windows deployment, including the new Windows Autopilot device preparation process.

This change is meant to help you and security teams ensure that only devices that are explicitly authorized can be marked as corporate-owned devices. Organizations can upload a comma-separated, values-formatted (.csv) list of devices, specifying manufacturer, model, and serial number (for Windows devices only). Details will be available in the documentation when this feature is released as it’s rolling out apart from the May 2024 update.

Screenshot of an uploaded a .csv file that contains identifying details of devices to be identified as corporate-owned.

Enrollment time grouping

You know that device groups are powerful tools for managing lots of devices. Before the introduction of this new capability, enrollment time grouping, new Windows devices would get policies only once the device’s properties are discovered and group memberships are evaluated. The result would have unpredictable wait times before devices were ready to use. The enrollment time grouping feature accelerates the process of group assignment and the time of productivity for end users by skipping the inventory discovery and dynamic membership evaluation phases. Enrollment time grouping is currently available as part of Windows Autopilot device preparation, which is being released at the end of May 2024 and will be expanded to other enrollment methods and platforms in the months ahead. To learn more, read this article on enrollment time grouping and Windows Autopilot device preparation.

Stay up to date! Bookmark the Microsoft Intune Blog and follow us on LinkedIn or @MSIntune on X to continue the conversation.

​Microsoft Tech Community – Latest Blogs –Read More 

Messaging about securing Copilot for Microsoft 365 with Microsoft 365 Business Premium and Business Standard (Business Basic coming soon) has been developed to support conversations around securing for AI in the small and medium-sized business (SMB) market.

Resources

Check out the Securing Copilot for Microsoft 365 in SMB deck to learn more
Visit the Business Premium Partner Playbook page for additional resources

—

Advanced Support for Partners (ASfP) and Premier Support for Partners (PSfP) are paid partner offerings at Microsoft that provide unmatched value through a wide range of Partner benefits including account management, technical cloud enablement consultations, and an elevated technical support experience across the Microsoft Cloud (Azure, Microsoft 365, Dynamics 365, Power Platform).  

Partners in ASfP have higher Microsoft AI Cloud Partner Program Capability Scores, attain more Solutions Partner designations, and see uplifts across Azure, M365, and D365.  View the data and learn more on the new ASfP Impact slide below.

Please review these resources to learn more and consider booking a meeting to speak directly with our teams for a better understanding of the value-added benefits of ASfP and PSfP.

Book a meeting with an ASfP Evangelist
Book a meeting with a PSfP Specialist
Visit the ASfP Website
Visit the PSfP Website
Download the ASfP Fact Sheet
View the ASfP Impact Slide
Stop by the ASfP Partner Community

​ 

 
Messaging about securing Copilot for Microsoft 365 with Microsoft 365 Business Premium and Business Standard (Business Basic coming soon) has been developed to support conversations around securing for AI in the small and medium-sized business (SMB) market.
 
Resources

Check out the Securing Copilot for Microsoft 365 in SMB deck to learn more
Visit the Business Premium Partner Playbook page for additional resources

 
—
Advanced Support for Partners (ASfP) and Premier Support for Partners (PSfP) are paid partner offerings at Microsoft that provide unmatched value through a wide range of Partner benefits including account management, technical cloud enablement consultations, and an elevated technical support experience across the Microsoft Cloud (Azure, Microsoft 365, Dynamics 365, Power Platform).  
 
Partners in ASfP have higher Microsoft AI Cloud Partner Program Capability Scores, attain more Solutions Partner designations, and see uplifts across Azure, M365, and D365.  View the data and learn more on the new ASfP Impact slide below.
 
Please review these resources to learn more and consider booking a meeting to speak directly with our teams for a better understanding of the value-added benefits of ASfP and PSfP.
 

Book a meeting with an ASfP Evangelist
Book a meeting with a PSfP Specialist
Visit the ASfP Website
Visit the PSfP Website
Download the ASfP Fact Sheet
View the ASfP Impact Slide
Stop by the ASfP Partner Community  Read More

​

Imagine transforming your everyday device into an AI powerhouse, capable of handling complex tasks with ease and efficiency. With the introduction of Surface’s new line of products, powered by cutting-edge Neural Processing Units (NPUs), this vision is now a reality. These specialized hardware components are set to revolutionize AI performance, bringing unprecedented speed, efficiency, and privacy to your fingertips.

What’s an NPU?

The NPU architecture is optimized for matrix operations, executing neural network layers quickly and accelerating inference with remarkable efficiency. By offloading AI workloads from the CPU or GPU, the NPU reduces power consumption, enabling better performance, longer-lasting battery life, and improved thermal management on the device. The NPU runs models locally on the device, reducing latency for real-time applications and giving developers more control over data privacy – the data never has to leave the device.

To learn more, see these Qualcomm resources:

What is an NPU? And why is it key to unlocking on-device generative AI? | Qualcomm
Whitepaper describing the need for an NPU and heterogeneous computing

Our journey begins

As data scientists on the Surface development team, we couldn’t wait to get our hands on our new PCs and leverage the NPU for our own models and applications. But before we jump into the deep end, we first need to understand the basics – how to connect to the NPU and run models on it. In this article, we’ll share our story about how we ran a “Hello World” model on the NPU, so you can do it too. We’ll walk you through the steps we took to deploy a classic Convolutional Neural Network (CNN) model, Handwritten Digit Classification, onto an NPU.

Building the model

We started with the creation of a “Hello World” neural network model using the publicly available MNIST dataset. The MNIST dataset contains images of handwritten digits (MNIST — Torchvision main documentation), and there are numerous blog posts online that provide guidance on how to train a classification model. (Here’s the one we used: MNIST Handwritten Digit Recognition in PyTorch – Nextjournal.) Note that you can swap this with any other trained model if you prefer.

Converting to ONNX

Since PyTorch models cannot directly run on the NPU, we converted our model to ONNX format using the PyTorch function `torch.onnx.export`. ONNX is a file format that allows models to be run on various hardware platforms and runtime environments. You can find a detailed tutorial on converting models to ONNX here: Exporting a Model from PyTorch to ONNX. If you use another framework, like TensorFlow, you will need to follow a similar conversion process.

TIP: We found that the NPU on Surface will not take a dynamic axis. Therefore, when you export it to ONNX format, you need to fix all the input dimensions including batch size. Here is a code snip we used to convert our Pytorch model to ONNX format.

dummy_input = torch.randn(1, 1, 28, 28) # dummy input has the same dimension with actual MNIST data. batch size*C*H*W = 1*1*28*28
torch.onnx.export(model, # model being run
dummy_input, # model input (or a tuple for multiple inputs)
“model.onnx”, # where to save the model (can be a file or file-like object)
export_params=True, # store the trained parameter weights inside the model file
opset_version=11, # the ONNX version to export the model to
do_constant_folding=True, # whether to execute constant folding for optimization
input_names = [‘input’], # the model’s input names
output_names = [‘output’] # the model’s output names
)

Configuring the development environment for NPU deployment

After converting the model to ONNX, we set up the development environment for running the model on the NPU. We followed the ONNX Runtime documentation for the QNN Execution Provider.

TIPS:

Software versions: Quantization must be done using the x64 version of Python. We recommend doing this in a virtual environment. To run the model, use Python(ARM) 3.11.x and NumPy 1.25.2. Before installing NumPy, install the Microsoft Visual C++ Build Tools and select the correct components.
Device-specific codes: When starting an ONNX Runtime session, specify the Hexagon Tensor Processor (HTP) architecture value. For the Qualcomm® Hexagon™ NPU on Copilot+ PCs, Surface Pro and Surface Laptop, the code is 73. This code is not publicly mapped, so assistance from the manufacturer might be necessary.
Library files: Ensure that shared library files (.so) are copied into the same project folder, not just the system directory.

Quantizing the model

Next, we quantized the model, converting the 32-bit floating point model to an 8-bit integer model. Quantization balances the trade-offs between model accuracy and computational efficiency. There are two primary types of quantization frameworks: dynamic and static.

The Qualcomm Hexagon NPU on Copilot+ PCs, Surface Pro and Surface Laptop, supports static quantization, which means both the weights and activations are quantized before deployment.

We followed the QNN documentation for pre-processing and quantization: Quantize ONNX Models. Using a static quantization method, we created calibration data with representative data samples to determine optimal quantization parameters. We used the default parameters in the documentation example: uint16 for activations and uint8 for weights. Now, we have a quantized ONNX model ready to run on the NPU!

 TIP: Supported ONNX operators. At the time of this blog post, not all operators can be quantized. To fully utilize NPU acceleration, ensure all layers are compatible with QNN. Check the supported operator set here: Supported ONNX operators.

Running the model

To run our model on the NPU, we started an ONNX Runtime inference. Different parameters can be configured to fit your particular use case: Configuration Options.

session = onnxruntime.InferenceSession(“model.qdq.onnx”, # path to our model
sess_options=options,
providers=[“QNNExecutionProvider”],
provider_options=[{“backend_path”: “QnnHtp.dll”}]) #Provide path to Htp dll in QNN SDK

We created a simple Flask app to give our model a user-friendly interface. Each time we ran our model, we observed the resource usage of our NPU in Task Manager, confirming that the NPU was indeed being utilized!

Conclusion

Our journey to run a “Hello World” model on the NPU was not without its share of challenges. There were many learnings along the way, most notably the agency we have in the quantization step to balance accuracy and efficiency. We believe this will be one of the most important considerations when we develop future applications.

Our other major learning is that certain tasks – like large neural network models, or reasoning over audio, vision, or language datatypes – are best suited for the NPU, whereas other tasks could be better suited for the CPU or GPU. The same way we experiment with different models during development, in future projects we plan to experiment with different implementation methods to determine which one is most performant, in terms of inference time and power consumption.

This exploration has only added fuel to our fire as we consider where we can take this next. We believe we can take advantage of the NPU’s unique power to build even greater Surface devices and experiences. (And we can’t wait to see what you do too!)

This space is growing fast, thanks to groups like the Applied Sciences Group at Microsoft, Qualcomm, and ONNX. With many libraries being open source, we anticipate these assets will only get better with time. Together, we can unlock the NPU’s limitless potential. How will you use it?

Learn more

What is an NPU? And why is it key to unlocking on-device generative AI? | Qualcomm
Whitepaper describing the need for an NPU and heterogeneous computing
MNIST — Torchvision main documentation
MNIST Handwritten Digit Recognition in PyTorch – Nextjournal
Quantize ONNX models | onnxruntime

​Microsoft Tech Community – Latest Blogs –Read More 

Hello all,

I have been trying to get the conditional show/hide for columns in library forms to work by following the tutorial located here (https://learn.microsoft.com/en-us/sharepoint/dev/declarative-customization/list-form-conditional-show-hide). Unfortunately, no matter what configuration I use, it does not work and the column never shows. The simplest iteration I tried was to have a column (Identifier) show where a Boolean value (IsPleading) is checked. The syntax is correct, but checking and unchecking the box does nothing, even with refresh, closing out of the browser and re-opening, and everything else I can think of. Can anyone help me with what I may be doing wrong? Screenshots below. My syntax for the “Identifier” column is “=if([$IsPleading] ==true,’true’,’false’)” I have also tried it with =if([$IsPleading] ==’Yes’,’true’,’false’), =if([$IsPleading] ==’1′,’true’,’false’) and =if([$IsPleading] ==’true’,’true’,’false’) as well as replacing the “$” with “@” and removing the brackets.

Any help is greatly appreciated!!

​Hello all, I have been trying to get the conditional show/hide for columns in library forms to work by following the tutorial located here (https://learn.microsoft.com/en-us/sharepoint/dev/declarative-customization/list-form-conditional-show-hide). Unfortunately, no matter what configuration I use, it does not work and the column never shows. The simplest iteration I tried was to have a column (Identifier) show where a Boolean value (IsPleading) is checked. The syntax is correct, but checking and unchecking the box does nothing, even with refresh, closing out of the browser and re-opening, and everything else I can think of. Can anyone help me with what I may be doing wrong? Screenshots below. My syntax for the “Identifier” column is “=if([$IsPleading] ==true,’true’,’false’)” I have also tried it with =if([$IsPleading] ==’Yes’,’true’,’false’), =if([$IsPleading] ==’1′,’true’,’false’) and =if([$IsPleading] ==’true’,’true’,’false’) as well as replacing the “$” with “@” and removing the brackets. Any help is greatly appreciated!!     Read More

​

We are excited to announce the launch of two new features in Azure Load Testing: multi-region load tests and support for Locust framework. Azure Load Testing is a fully managed service for performance testing that helps developers and testers easily generate high scale load and identify performance bottlenecks.

With multi-region load tests, you can now simulate load from multiple geographies simultaneously in a single test run, to closely mimic the real-life traffic patterns. With the in-built dashboard, you get an aggregate view of performance across regions, and you can drill down to a specific region and compare performance metrics across regions. Running multi-region load tests will also help you better validate your network architecture, load balancing components and failover capabilities. This feature is now generally available.

Azure Load Testing now supports Locust, a Python based open-source framework for performance testing. Locust is a developer friendly framework that lets you write code to create load test scripts as opposed to using GUI based test creation. You can check-in the scripts into your repos, seek peer feedback and better maintain the scripts as they evolve, just like developers would do for any other piece of code. You can use your existing Locust scripts as is and run them at scale using Azure Load Testing to unlock the benefits of a managed service. You can now use JMeter or Locust or a combination of both depending on your familiarity with the framework and the suitability for your scenarios. This feature is currently in limited preview, and you can sign up here.

Let’s see how these two features can help us validate the performance of the Contoso Traders web application (a fictitious, sample app for demos) across various geographical locations.

Author a test script using Locust

Contoso Traders e-commerce web application provides an online shopping experience where users can browse various products by categories, view product details, view the cart etc. Now, we want to simulate a simple user flow where users visit the homepage, view the list of products and add a product to the cart. We can write Python code and create a Locust script for this scenario.

This is a basic Locust script. You can more realistically mimic the user behavior by using various constructs that Locust supports. You can use Locust plugins, provide test data using a CSV file, use config files with Locust etc. and seamlessly get those working with Azure Load Testing.

Here, we used Locust for test script creation. However, you can also use JMeter or configure the requests directly in the Azure Load Testing experience.

Run the test and analyze results using Azure Load Testing

Now, let’s take the script that we just created to Azure Load Testing and simulate a global usage pattern.

To create a test in Azure Load Testing, we just upload the script and specify the load that we wish to simulate.

To simulate load from users across the globe, we just have to select the regions from which we need to generate load and the share of load from each region. The service takes care of the rest.

Once the test is run, we can see a rich dashboard showing a summary of how the e-commerce application fared overall and a comparison of performance metrics across the regions. We can also slice and dice to view metrics specific to a combination of requests, regions, error types etc., that we are interested in and quickly find out anomalies. We can also correlate the client-side performance with the server-side metrics to easily identify the bottlenecks.

We used Locust to create a test script to simulate a user flow on Contoso Traders web application and used that script with Azure Load Testing to test the web app performance. To closely simulate the real time traffic pattern, we used a multi-region load test to generate load from multiple geographies.

Next steps

Multi-region load tests feature is now generally available. Detailed steps to try it out are available here – Generate load from multiple regions – Azure Load Testing | Microsoft Learn
Support for Locust framework is now in limited preview. You can sign up for the preview here – https://aka.ms/alt-locust-signup

We also have some interesting updates about the integration of Azure Load Testing with Azure App Service and Azure Functions. Check out these links to know more  

https://aka.ms/performance-optimizer-blog

https://aka.ms/ALT-AppService 

https://aka.ms/ALT-Functions 

Try out the exciting new features and share your feedback here – https://aka.ms/malt-feedback

​Microsoft Tech Community – Latest Blogs –Read More