Kategorie: Microsoft Azure

Now Generally Available: On-premises data gateway in Azure

With today's update, we're excited to announce that the on-premises data gateway is now generally available in Azure. This gateway helps you securely connect your business apps in the cloud to your data sources on premises. You can use the gateway to move data to and from the cloud while keeping your data sources on premises. The gateway currently supports Azure Logic Apps, but in the next few months, will also expand to support Azure Analysis Services.

This release includes these new features:

Support for multiple regions
Delete your gateway connection resource in Azure
New on-premises connectors for Azure Logic Apps

To get the latest gateway installation, download the gateway installer.

Support for multiple regions

This update gives gateway admins even more control over data gateway settings. When you install the gateway on a local computer, you can now select the region for the gateway cloud service and Azure Service Bus communication channel that you want to use with your gateway installation. Previously, this region defaulted to your Azure Active Directory tenant’s location.

We will move existing gateways to match the original location of your tenant. So if you currently use the gateway, you might notice this change. However, this update won't affect currently running logic apps, which will continue to work as usual.

Note: You can't change this region after installation unless you uninstall the gateway and reinstall. This region also determines and restricts the location where you can create the Azure resource for your gateway connection. So when you create the gateway connection resource in Azure, make sure to choose the location that you selected during installation so you can select your gateway from the installed gateways list.

Delete gateway resource in Azure

You can now delete your gateway connection resource in Azure and associate your gateway to a different Azure resource. The ability to delete the gateway installation is coming soon.

New on-premises connectors for Azure Logic Apps

Also, we’re adding new connectors that support on-premises data sources for Azure Logic Apps, Oracle EBS and PostgreSQL. These connectors follow two other connectors that we introduced a month ago, MySQL and Teradata.

Learn more about how to access data sources on premises through the data gateway for Azure Logic Apps.
Quelle: Azure

1400 compatibility level in Azure Analysis Services

We are excited to announce the public preview of the 1400 compatibility level for tabular models in Azure Analysis Services! This brings a host of new connectivity and modeling features for comprehensive, enterprise-scale analytic solutions delivering actionable insights. The 1400 compatibility level will also be available in SQL Server 2017 Analysis Services, ensuring a symmetric modeling capability across on-premises and the cloud.

Here are just some highlights of the new features available to 1400 models.

New infrastructure for data connectivity and ingestion into tabular models with support for TOM APIs and TMSL scripting. This enables:

Support for additional data sources, such as Azure Blob storage.
Data transformation and data mashup capabilities.

Support for BI tools such as Microsoft Excel enable drill-down to detailed data from an aggregated report. For example, when end-users view total sales for a region and month, they can view the associated order details.
Object-level security to secure table and column names in addition to the data within them.
Enhanced support for ragged hierarchies such as organizational charts and chart of accounts.
Various other improvements for performance, monitoring and consistency with the Power BI modeling experience.

To benefit from the new features for models at the 1400 compatibility level, you’ll need to download and install SQL Server Data Tools (SSDT) 17.0.

In SSDT, you can select the new 1400 compatibility level when creating new tabular model projects. Alternatively, you can upgrade an existing tabular model by selecting the Model.bim file in Solution Explorer and setting the Compatibility Level to 1400 in the Properties window. Models at the 1400 compatibility level cannot be downgraded to lower compatibility levels.

New Infrastructure for Data Connectivity

1400 models introduce a new infrastructure for data connectivity and ingestion into tabular models with support for TOM APIs and TMSL scripting. This is based on similar functionality in Power BI Desktop and Microsoft Excel 2016. At this point, only the following cloud-based data sources are supported with the 1400 compatibility level in Azure Analysis Services. We intend to add support for more data sources soon. For more information, please refer to the Analysis Services Team blog, and watch out for future posts to the Azure blog.

Azure SQL Data Warehouse
Azure SQL Database
Azure Blog Storage

Detail Rows

A much-requested feature for tabular models is the ability to define a custom row set contributing to a measure value. Multidimensional models achieve this by using drillthrough and rowset actions. This allows end-users to view information in more detail than the aggregated level.

For example, the following PivotTable shows Internet Total Sales by year from the Adventure Works sample tabular model. Users can right-click the cell for 2010 and then select the Show Details menu option to view the detail rows.

By default, all the columns in the Internet Sales table are displayed. This behavior is often not meaningful for the user because too many columns may be shown, and the table may not have the necessary columns to show useful information such as customer name and order information.

Detail Rows Expression Property for Measures

1400 models introduce the Detail Rows Expression property for measures. It allows the modeler to customize the columns and rows returned to the end user. The following example uses the DAX Editor in SSDT to define the columns to be returned for the Internet Total Sales measure.

With the property defined and the model deployed, the custom row set is returned when the user selects Show Details. It automatically honors the filter context of the cell that was selected. In this example, only the rows for 2010 value are displayed.

Further information on Detail Rows is available in this blog post.

Object-Level Security

Roles in tabular models already support a granular list of permissions, and row-level filters to help protect sensitive data.

1400 models introduce table- and column-level security allowing sensitive table and column names to be protected in addition to the data within them. Collectively these features are referred to as object-level security (OLS).

The current version requires that OLS is set using the JSON-based metadata, Tabular Model Scripting Language (TMSL), or Tabular Object Model (TOM). We plan to deliver SSDT support soon. The following snippet of JSON-based metadata from the Model.bim file secures the Base Rate column in the Employee table of the Adventure Works sample tabular model by setting the MetadataPermission property of the ColumnPermission class to None.

"roles": [

  {

    "name": "General Users",

    "description": "All allowed users to query the model",

    "modelPermission": "read",

    "tablePermissions": [

      {

        "name": "Employee",

        "columnPermissions": [

           {

              "name": "Base Rate",

              "metadataPermission": "none"

           }

        ]

      }

    ]

  }

Unauthorized users cannot access the Base Rate column using client tools like Power BI and Excel Pivot Tables. Additionally, such users cannot query the Base Rate column using DAX or MDX, or measures that refer to it.

Further information on OLS is available in this blog post.

Ragged Hierarchies

Tabular models with previous compatibility levels can be used to model parent-child hierarchies. Hierarchies with a differing number of levels are referred to as ragged hierarchies. An example of a ragged hierarchy is an organizational chart. By default, ragged hierarchies are displayed with blanks for levels below the lowest child. This can look untidy to users, as shown by this organizational chart in Adventure Works:

1400 models introduce the Hide Members property to correct this. Simply set the Hide Members property to Hide blank members.

With the property set and the model deployed, the more presentable version of the hierarchy is displayed.

Other Features

Various other features such as the following are also introduced with the 1400 compatibility level. For more information, please refer to the Analysis Services Team blog for what's new in SQL Server 2017 CTP 2.0 and SQL Server vNext on Windows CTP 1.1 for Analysis Services.

Transaction-performance improvements for a more responsive developer experience.
Dynamic Management View improvements enabling dependency analysis and reporting.
Hierarchy and column reuse to be surfaced in more helpful locations in the Power BI field list.
Date relationships to easily create relationships to date dimensions based on date columns.
DAX enhancements to make DAX more accessible and powerful. These include the IN operator and table/row constructors.

Try it Now!

To get started, simply create a 1400 model in SSDT and deploy it to Azure Analysis Services! See this post on how to create your first model. Be sure to keep an eye on this blog to stay up to date on Azure Analysis Services.
Quelle: Azure

Azure IoT Hub Server TLS Leaf certificate renewal – May 2017

The following blog contains important information about TLS certificate renewal for Azure IoT Hub endpoints which may impact client connectivity.

As part of the periodic renewal cycle, the Azure IoT Hub leaf certificates used for TLS connection will be renewed starting mid-May 2017. This could potentially impact some clients connecting to the Azure IoT Hub service. This change only impacts Azure IoT Hubs created in public Azure cloud, and not Azure in China nor Azure Germany.

Certificate renewal summary

The table below provides information about the certificate being renewed. Depending on which cert your device or gateway clients use for TLS connection, action may be needed to prevent loss of connectivity.

Expected behavior

Not impacted: Devices connecting to Azure IoT Hub using Azure IoT Device or Gateway SDK, as provided. Using your own connection code that utilizes the root certificate or SDKs using the Operating System's built-in Certificate Store for TLS connection will not be impacted. 
Potentially impacted: Devices using a connection stack other than the connection stack provided in an Azure IoT SDK. Specifically, connection logic that pins the leaf certificate will experience TLS connection failures after the rollover if not updated. Our recommendation is to pin the root certificates as they renew less frequently.

Validation

We recommend validation to mitigate any untoward impact to your IoT infrastructure connecting to Azure IoT Hub. We have setup a test environment for your convenience to try out before we renew the leaf certificate in Azure IoT Hub. The connection string for this test environment is: HostName=playground01.df.azure-devices-int.net;SharedAccessKeyName=owner;SharedAccessKey=0DvHNevPwsDjpMor6eT6aZefKp77Tdo7z2eaFX9kF5I=

A successful TLS connection to the test environment signifies a positive test outcome, and that your infrastructure will work with this change. This connection test string contains an invalid key so once the TLS connection is established, any runtime operations performed against this test IoT Hub will fail. This is by design as the hub exists solely for customers to validate their TLS connection functions. This test environment will be available until all public cloud regions have been updated.

If you have any technical questions on implementing these changes, open a support request with the options below and an engineer will get back to you shortly.

Issue Type: Technical
Azure Service: Internet of Things/IoT SDKs
Problem Type: Security/Authentication
Glossary of terms: Root, Intermediate, and Leaf certificates – Types of digital certificates also known as public key or Identity certificates used to manage identity, access, and trust over a network.

Quelle: Azure

New Power BI content pack for Azure Enterprise users

We are excited to announce the release of the new Power BI content pack for Azure Enterprise users which enables exploration and analysis of consumption data for enterprise enrollments. The data will be refreshed automatically once per day.

What's new?

The ability to specify a time range up to 36 months.
The content pack now includes Marketplace, Balance, and Summary data for the time range specified.
Price sheet data for the current billing period has also been added.
Addressed bugs in the previous version, as well as increased stability and performance.

Here are the steps to get started:

Navigate to Microsoft Azure Consumption Insights and click Get It Now.
Provide Enrollment Number and Number of Months and click Next.
Provide your API access key to connect, see details below.
The import process will begin automatically. When complete, a new dashboard, report, and model will appear in the navigation pane. Click the dashboard to view your imported data.

For more information on how to generate the API key for your enrollment, please visit the API Reports help file on the Enterprise Portal. For more information on the new content pack, please download the Microsoft Azure Consumption Insights document.

As always, please reach out to us on the Azure Feedback forum (add #pbicp2) and through the Azure MSDN forum.
Quelle: Azure

Understanding performance and usage impact of releases using annotations in Application Insights

A little over a year ago, the Application Insights team re-introduced release annotations so that users would have the ability to correlate occurrences of app and services releases with their APM data. VSTS users can simply add a step to their release scripts to create annotations, and users leveraging third-party release engines can push release annotations to Application Insights by simply calling a Powershell script.

In the meantime, the VSTS team has been hard at work maturing continuous integration/deployment functionality in the VSTS release tools, as well as extending that functionality to many other platforms. As the concept of CI/CD continues to gain momentum and popularity in development shops around the world, the value of generating annotations for the associated tighter release cycle increases dramatically.

A simple example

In the above illustration, we have an app called MyEnterpriseApp being regularly deployed through continuous deployment. Two statistics have been chosen here: Users and browser page load time. Since annotations have been added to the release script, we can clearly see when our releases are occurring, and how they may be affecting performance or usage. In the earlier part of the chart, we see a very normal cadence of users: daily spikes during prime weekday hours, with valleys at night, followed by a lower number of users on the weekend. Our page load time is consistently around two seconds or less, and so our user base remains equally consistent.

If we look at the release that happens the following week (around April 17th on this chart), however, a problem is clearly introduced. Page load times shoot up to around eight seconds, and our number of active users goes into a nose-dive, dropping off dramatically until the number of users tolerating this level of performance is actually lower than what we would normally see on weekends. Following these events, we see another release around April 19th, which we can safely assume includes some kind of fix for the situation, because following the release our page load times drop back the normal range, and our active user count rebounds as well now that performance is back to an acceptable state.

So what happened? Was the release not tested properly? Did an environmental factor exist in production that wasn’t present in test? The natural next step is to investigate the problem to ensure it doesn’t happen again. Again, we can leverage our release annotations to begin drilling to greater detail to solve the issue. Remember that we can hover on an annotation, and it will give us information about the release:

If we click on the information balloon, a detail blade opens up describing the release, complete with a link to the release script in VSTS (or a 3rd-party system, so long as that was provided when the annotation was created through the Powershell script):

In this way, we can quickly see who we should contact about the release, and investigate individual steps or deployed components (if we suspect a code error was introduced).

Since we can save Metrics Explorer results as favorites, we can retain the view of these significant statistics for future use. This allows us to come back in the following days and very quickly get a view of our releases to ensure that our errors are not being repeated, or allow us to investigate them immediately if they are. Simply being able to correlate our releases with our performance and usage data by use of release annotations dramatically reduces the time required for confirmation or investigation.

As always, please share your ideas for new or improved features on the Application Insights UserVoice page. For any questions visit the Application Insights Forum.
Quelle: Azure