Azure Sphere version 21.04 is now available

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

The Azure Sphere 21.04 feature release includes the following components:

• Updated Azure Sphere OS


• Updated Azure Sphere SDK for Windows and for Linux


• Updated Azure Sphere extensions for Visual Studio and for Visual Studio Code

There’s also a new version of the reference development board (RDB) design, new or updated samples, and a new Application note on Wi-Fi configuration options.

If your devices are connected to the internet, they will receive the updated OS from the cloud. You’ll be prompted to install the updated SDK on next use, or you can install it now. To install the latest SDK, see the installation Quickstart for Windows or Linux:

• Quickstart: Install the Azure Sphere SDK for Windows


• Quickstart: Install the Azure Sphere SDK for Linux

New and changed features in the 21.04 release

Peripheral configuration locking

Azure Sphere chips now have the ability to lock a peripheral configuration. This prevents an attacker from reassigning peripherals even if code is compromised. Thus, peripheral configuration locking adds another layer of security.

Time sync changes

The 21.04 release changes the client ports used by the Azure Sphere device. Previously, the device always used client source port 124. After this release it will use a random UDP client source port between 32678-61000. If this port fails, Azure Sphere then attempts to use port 124 as the UDP client source port.

Ethernet enabled by default

The 21.04 release changes the way the ethernet interface is enabled. Previously, a developer needed to call the Networking_SetInterfaceState command to enable ethernet. After this release, ethernet will automatically be enabled on first reboot after an ethernet board configuration is loaded.

Wi-Fi improvements

The Wi-Fi client performs background scanning at regular intervals. In some cases the client could disconnect when the wi-fi background scan occurred at the same time that a device registered a “beacon lost” signal. We have introduced an offset in the two signals so the system will now listen for beacon signals beyond the scan time.

Delete a product or device group with the CLI

CLI support for deleting a product is now available using the azsphere product delete command.

CLI support for deleting a device group is now available using the azsphere device-group delete command.

View statistics on total memory usage

The azsphere device app show-memory-stats command returns memory usage statistics on total memory usage, user mode usage, and peak user-mode usage for applications running on an attached device. The device must have the appDevelopment device capability configured to run this command.

Support for crash data collection

Optional diagnostic data can now be configured using the CLI to collect a full Linux core dump when an application or system service crashes. You can give consent to enable crash dump collection by using the –allow-crash-dumps-collection parameter in the azsphere device-group update command.

Write capabilities added to Azure Sphere Explorer for Visual Studio or Visual Studio Code

Azure Sphere Explorer for Visual Studio now has the ability to create and update products and device groups. Other changes were made to both the Visual Studio and Visual Studio Code versions of Azure Sphere Explorer to make them functionally equivalent.

Multiple device support in Azure Sphere Explorer for Visual Studio or Visual Studio Code

Azure Sphere Explorer now supports multiple connected devices. One device can be chosen as the active device for a given project. Deployment and debugging of the project is then done on the active device.

New and updated samples, code snippets, and Gallery items

The 21.04 release includes a refactored Azure IoT sample, a new code snippet, and several new items in the Azure Sphere Gallery.

Refactored Azure Sphere sample app for connecting to Azure IoT

Updates to the Azure IoT sample include:

• Dedicated guidance (READMEs) for each starter scenario (connect to Azure IoT Hub or Azure IoT Central) and for each add-on scenario (connecting via the device provisioning service and/or via Azure IoT Edge).


• Refactored codebase with smaller, easier-to-assemble pieces.


• Support for Azure IoT Plug and Play (PnP) – so that the device’s data model “template” is auto-populated when using Azure IoT Central or a PnP-aware client connected to Azure IoT Hub.


• Updated best practice for using the Azure IoT C SDK, in particular to enable connections via the device provisioning service to be established asynchronously.

New code snippet on memory usage

A new code snippet on memory usage demonstrates how to detect and handle unexpected memory usage.

Github gallery samples

More than 10 new projects added to the Azure Sphere Gallery GitHub repository, including:

• tools to evaluate networks’ compatibility with Azure Sphere OS.


• tools to use the littlefs file system.


• a complete design of a realtime demo device (balancing robot), including software, hardware, and mechanical designs.

Hardware reference design changes

Changes to the hardware design of the MT3620 reference development board (RDB) have been made for version 1.7. These changes have been identified through extensive use of the board (both internally and via customer feedback) and as a result of software changes that have enabled features such as Power Down that were not supported at the time the board was originally designed.

The MCU programming and debugging interface has been modified to include a second schematic showing a circuit that enables the PC and reset button to bring a device out of Power Down mode. This is a backwards-compatible change with no changes required to the SDK.

For more information on the 21.04 release, please see the What’s new in Azure Sphere in the customer documentation. To learn about Azure Sphere OS feeds and setting up an evaluation device group, see Azure Sphere OS feeds and Set up devices for OS evaluation.

For self-help technical inquiries, please visit Microsoft Q&A or Stack Overflow. If you require technical support and have a support plan, please submit a support ticket in Microsoft Azure Support or work with your Microsoft Technical Account Manager. If you would like to purchase a support plan, please explore the Azure support plans.

How to get Source Code files for Power Apps Canvas apps

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

This post will guide you through the process of how to use the Power Apps Language Toolkit to extract a Power Apps .msapp file. 

why would you want to have the source code files? 

To make your app reusable, so that more people can benefit from it, you will want to share the source code files. Unfortunately, when you save your Canvas App from Power Apps Studio, it is saved in one opaque .msapp file. To be able to get the source files, you will need to use the Power Apps Language Toolkit to extract all files from the .msapp file. This way,

• developers can not only open the source code in their code editor of choice but can effectively manage the code of a Canvas app in GitHub or Azure DevOps. This makes a huge difference as we can’t look into .msapp files.


• makers can still open the .msapp file to easily import an app sample into their environment

Prerequisites

To be able to use the Power Apps Language Toolkit, you will need to

• install Visual Studio Code 


• install .NET Core 3.1.x (x64) 


• download the Power Apps Language Toolkit
  
  
  
  • go to github.com/microsoft/PowerApps-Language-Tooling 
  
  
  • select Code
  
  
  • select Download ZIP
  
  
  
  


•  extract the Power Apps Language Toolkit to a local folder


•  open that local folder


• locate the build.cmd file


• rightclick, Run as Administrator


• in the Pop up Window, select more info


• select Run anyway

Please note, that command Prompt will open, show a few lines and then close automatically again.
Please also not, that you can now find a bin folder in the local folder you extracted the PowerApps Language Toolkit to. In this bin folder, you will find a Debug folder and inside of the Debug folder you will find a PASopa folder.

Download the .msapp file

• go to [make.powerapps.com](https://make.powerapps.com)


• log in


• open your app in edit mode


• select File


• select Save as


• select This Computer


• select Download


• move the downloaded .msapp file to your folder in which you extracted the PowerApps Language Toolkit as well

unpack .msapp file

• Now that we have the .msapp file of the app:


• press the WINDOWS key on your keyboard and search for Command Prompt (first few letters should do)


• run as an Administrator


• copy the path of the PASopa folder


•  type in Command Prompt `cd <your PASopa path>`


• copy the path of the .msapp file


• create a new folder in your app folder


• copy the path of that new folder


• type in Command Prompt `pasopa -unpack <your msappfile path> <new folder path>`

Please note that you will now find all source code files in that new folder. You can open the folder in a code Editor of your choice, for example Visual Studio Code.

submit as a sample

Well done! If you like to contribute with your app to the PnP Power Apps sample gallery , you can submit your app with these source code files here. To do so, follow these steps: 

Now you can submit these source code files as a sample. Please

• fork the PnP PowerApps repository 


• commit your files


• Pull Request by filling out the PR template

Please do not forget to provide as well a `README.md` file which explains what your sample is about.

If this all sounds confusing to you and you are new on GitHub – you are more than welcome to attend the Sharing Is Caring sessions, where we guide you through using GitHub and making your first PR. 

Sharing Is Caring :sparkling_heart:

Cross-instance distributed transactions with Azure SQL Managed Instance

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

With Azure SQL Managed Instance, you don’t need MS DTC to run distributed transactions! You can now migrate to Azure or build distributed applications with Managed Instance which natively supports cross-instance T-SQL and .NET distributed transactions. 

With recent modernization, distributed transactions are supported between Managed Instances as the only supported transaction participants. If your application runs .NET or T-SQL distributed transactions on SQL Server and of course requires MS DTC for that, you can now migrate to Azure SQL Managed Instance and distributed transactions will simply work. Also, if you need to build a multi-server environment in the cloud that needs to run queries in a transactionally consistent fashion, Managed Instance with native support for distributed transactions is a great place for your app.

Distributed transactions on Managed Instance can easily be setup with two simple steps:

1. Create Server trust group.


2. Ensure there is network connectivity between your instances.

In the rest of the blog, you will get more info on how to easily setup your Managed Instance to run distributed transactions.

Creating a Server trust group

Server trust group (STG) is an entity that manages security requirements for running distributed transactions. You can create it in Azure Portal, or via Azure PowerShell  or Azure CLI.

Here is an example of Azure PowerShell script that creates STG for two Managed Instances.

Login-AzAccount
Select-AzSubscription -SubscriptionId “c829c89a-0931-4310-a49c-fa8f42a8cff2”
$managedInstanceList = @()
$managedInstanceList += Get-AzSqlInstance -Name “sqlmi1” -ResourceGroupName “rg1”
$managedInstanceList += Get-AzSqlInstance -Name “sqlmi2” -ResourceGroupName “rg1”
New-AzSqlServerTrustGroup -ResourceGroupName “rg1” -Location “West Europe” -Name “stg1” -GroupMember $managedInstanceList -TrustScope “GlobalTransactions”

Network connectivity

For distributed transactions to work, there must be a network connectivity between Managed Instances. If instances are on different virtual networks, VNET peering needs to be setup. 
Additionally, port 5024 and port range 11000-12000 need to be allowed for outbound and inbound VNET traffic in the Network Security Groups assigned to Subnets that host Managed Instances.

Note: when Server trust group is not created, or there is no network connectivity between instances, distributed transaction will fail with following error message.

Msg 8510, Level 20, State 3, Line 14
Enlist operation failed: Global Transaction failed. SQL Server could not register with Microsoft Distributed Transaction Coordinator (MS DTC) as a resource manager for this transaction. The transaction may have been stopped by the client or the resource manager.

Distributed Transaction examples

With STG and network settings in place, you can run distributed transactions across Managed Instances with linked servers.

Here’s an example with two SELECT queries against master database.

SET XACT_ABORT ON

BEGIN DISTRIBUTED TRANSACTION

	— select from local server

	SELECT * FROM master.sys.databases

	— select from remote, linked server

	SELECT * FROM [linked_server_02].master.sys.databases

COMMIT

Here is another example with INSERT queries against user databases.

SET XACT_ABORT ON

BEGIN DISTRIBUTED TRANSACTION

	— insert into local server

	INSERT INTO db01.dbo.t01 (tag, utc_time)

		VALUES (‘distributed_transaction_tag’, GETUTCDATE())

	— insert into remote, linked server

	INSERT INTO [linked_server_02].db01.dbo.t01 (tag, utc_time)

		VALUES (‘distributed_transaction_tag’, GETUTCDATE())

COMMIT

Additional examples with .NET TransactionScope are available in the documentation.

Security baseline for Microsoft 365 Apps for enterprise v2104 – FINAL

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

Microsoft is pleased to announce the final release of the recommended security configuration baseline settings for Microsoft 365 Apps for enterprise, version 2104. Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and implement as appropriate. If you have questions or issues, please let us know via the Security Baseline Community or this post.

This baseline builds on the previous Office baseline we released mid-2019. The highlights of this baseline include:

• Restrict legacy JScript execution for Office to help protect remote code execution attacks while maintaining user productivity as core services continue to function as usual.


• Expanded macro protection requiring application add-ins to be signed by a trusted publisher. Also, turning off Trust Bar notifications for unsigned application add ins and blocking them to silently disable without notification.


• Block Dynamic Data Exchange (DDE) entirely.

Also, see the information at the end of this post regarding updates to Security Policy Advisor and Office Cloud Policy Services.

The downloadable baseline package includes importable GPOs, a script to apply the GPOs to local policy, a script to import the GPOs into Active Directory Group Policy, updated custom administrative template (SecGuide.ADMX/L) file, all the recommended settings in spreadsheet form and a Policy Analyzer rules file. The recommended settings correspond with the administrative templates version 5146, released March 22, 2021.

Changes since the Draft

A couple small changes were made since the Draft baseline released last month.

• Naming – We were reminded shortly after the Draft released (which was actually reviewed) that we no longer call the product Office 365 ProPlus, it will now be referred to as Microsoft 365 Apps for enterprise.


• GPO changes – We removed the Application Guard settings, while secure, there are conditions where preventing users from exiting App Guard may have an unacceptable end-user productivity impact as Application Guard continues to evolve to handle more file types and active content.

GPOs included in the baseline

Most organizations can implement the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We’ve broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script (Baseline-LocalInstall.ps1) offers command-line options to control whether these GPOs are installed.

The “MSFT M365 Apps for enterprise 2104” GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs, each of which is described later:

• “Legacy JScript Block – Computer” disables the legacy JScript execution for websites in the Internet Zone and Restricted Sites Zone.


• “Legacy File Block – User” is a User Configuration GPO that prevents Office applications from opening or saving legacy file formats.


• “Require Macro Signing – User” is a User Configuration GPO that disables unsigned macros in each of the Office applications.


• “DDE Block – User” is a User Configuration GPO that blocks using DDE to search for existing DDE server processes or to start new ones.

Restrict legacy JScript execution for Office Apps

The JScript engine is a legacy component in Internet Explorer which has been replaced by JScript9. Some organizations may have Office applications and workloads relying on this component, therefore it’s important to determine whether legacy JScript is being used to provide business-critical functionality before you enable this setting. Blocking the legacy JScript engine will help protect against remote code execution attacks while maintaining user productivity as core services continue to function as usual. As a security best practice, we recommend you disable legacy JScript execution for websites in Internet Zone and Restricted Sites Zone. We’ve enabled a new custom setting called “Restrict legacy JScript execution for Office” in the baseline and provided it in a separate GPO “MSFT M365 Apps for enterprise 2104 – Legacy JScript Block – Computer” to make it easier to deploy. Learn more about Restrict JScript at a Process Level.

Note: It can be a challenge to identify all applications and workloads using the legacy JScript engine, it’s often used by a webpage by setting the script language attribute in HTML to Jscript.Encode or Jscript.Compact, it can also be used by the WebBrowser Control (WebOC). After the policy is applied, Office will not execute legacy JScript for the internet zone or restricted site zone websites. Therefore, applying this Group Policy can impact the functionalities in an Office application or add-ins that require the legacy JScript component and users aren’t notified by the application that legacy JScript execution is restricted. Modern JScript9 will continue to function for all zones.

Important: If you disable or don’t configure this Group Policy setting, legacy JScript runs without any restriction at the application level.

Comprehensive blocking of legacy file formats

In the last Office baseline we published, we blocked legacy file formats in a separate GPO that can be applied as a cohesive unit. There are no changes to the legacy file formats recommended to block.

Blocking DDE entirely

Excel already disabled Dynamic Data Exchange (DDE) as an interprocess communication method, and now Word added a new setting “Dynamic Data Exchange” that we have configured to a disabled state. Because of the new addition from Word the existing GPO has been renamed to “MSFT M365 Apps for enterprise 2104 – DDE Block – User”.

Macro signing

The “VBA Macro Notification Settings” policy has been updated for Access, Excel, PowerPoint, Publisher, Visio, and Word with a new option. To further control macros we now recommend that macros also need to be signed by a Trusted Publisher. With this new recommendation macros not digitally signed by a Trusted Publisher will be blocked from running. Learn more at Upgrade signed Office VBA macro projects to V3 signature.

Note: Enabling “Block macros from running in Office files from the Internet” continues to be considered part of the main baseline and should be enforced by all security-conscious organizations.

Other changes in the baseline

• New policy: “Control how Office handles form-based sign-in prompts” we recommend enabling and blocking all prompts. This results in no form-based sign-in prompts displayed to the user and the user is shown a message that the sign-in method isn’t allowed.


• New policy: We recommend enforcing the default by disabling “Disable additional security checks on VBA library references that may refer to unsafe locations on the local machine” (Note: This policy description is a double negative, the behavior we recommend is the security checks remain ON).


• New policy: We recommend enforcing the default by disabling “Allow VBA to load typelib references by path from untrusted intranet locations”. Learn more at FAQ for VBA solutions affected by April 2020 Office security updates.


• New dependent policy: “Disable Trust Bar Notification for unsigned application add-ins” policy had a dependency that was missed in the previous baseline. To correct, we have added that missing policy, “Require that application add-ins are signed by Trusted Publisher”. This applies to Excel, PowerPoint, Project, Publisher, Visio, and Word.


• Removed from the baseline: “Do not display ‘Publish to GAL’ button”. While this setting has been there for a long time, after further research, we believe this setting is used to ensure good deployment practices and not to mitigate security concerns.

Deploy policies from the cloud, and get tailored recommendations for specific security policies

Deploy user-based policies from the cloud to any Microsoft 365 Apps for enterprise client through the Office cloud policy service. The Office cloud policy service allows administrators to define policies for Microsoft 365 Apps for enterprise and assign these policies to users via Azure Active Directory security groups. Once defined, policies are automatically enforced as users sign in and use Microsoft 365 Apps for enterprise. No need to be domain joined or MDM enrolled, and it works with corporate-owned devices or BYOD. Learn more about Office cloud policy service.

Security Policy Advisor can help give you insights on the security and productivity impact of deploying certain security policies. Security Policy Advisor provides you with tailored recommendations based on how Office is used in your enterprise. For example, in most customer environments, macros are typically used in apps such as Excel and only by specific groups of users. Security Policy Advisor helps you identify groups of users and applications where macros can be disabled with minimal productivity impact, and optionally integrate with Microsoft Defender for Office to provide you details on who is being attacked. Learn more about Security Policy Advisor.

When can I expect the next release of M365 Apps for enterprise Security Baseline?

In the future we will align the release of new security baselines with the M365 Apps for enterprise semi-annual channel releases, every 6 months usually in June and December. If there are no new policies to consider at that time, we will evaluate again 6 months later.

As always, please let us know your thoughts by commenting on this post.