One of the cool things about working in Microsoft is that we have plenty  of resources as internal as externals to solve the engineering problem. With the new setup for the Power BI Report Server we have the option to use our traditional test system or try something new, Azure DevTest Labs offer some of the features that are attractive for this type of end to end testing

• Quick provision of fresh new machines to install the product
• Automatic expiration of lab machines
• Integration with Visual Studio Team Services (VSTS)
• Secret management (integration with KeyVault)

DevTestLabs offer more features that we might use in the future.

The workflow is:

1. A download path for the to the latest build of PowerBIReportServer.exe is commited to the Git repo where the setup tests code is.
2. The build process starts (as part of the VSTS continuous  integration configuration), builds the test bits and download the setup file
3. A new machine is created in DevTestLabs (with SQL Server Engine and configured with access from VSTS)
4. The tests bits are copied to the machine and tests are executed

The workflow is simple but requires some components that aren’t available natively in VSTS

Setup the machine in DevTestLabs with artifacts

A new DevTestLab environment is created in the Azure Portal the detailed instructions are available in Create a lab in Azure DevTest Labs

The machine image is a simple Windows 2016 Server without anything configured on it, for the additional components DevTestLabs artifacts are used, the artifacts are reusable component to deploy and configure the machine in DevTestLabs.

The artifact for installing SQL Server is available in my Git repo here , you will need to update the placeholder ReplaceWithSQLServerDownloadPath in the InstallSQLServer2016Dev.ps1 with a url where you host your SQL Server 2016 setup bits, the artifact automates the installation of the SQL Server Engine.

The second artifact is the configuration of WinRM which is required to be able to execute commands remotely from VSTS, the artifact called InstallWinRM is available here , it is based in the instructions to Manage a virtual Machine in Azure DevTest Labs from the visualstudio.com documentation (https://www.visualstudio.com/en-us/docs/build/apps/cd/azure/deploy-provision-devtest-lab) and the great blog post from Tarun Aurora https://www.visualstudiogeeks.com/blog/DevOps/Configure-winrm-with-ARM-template-in-AzureDevTestLab-VM-deployment-using-PowerShell-artifact.

Those artifacts are hosted in the team’s internal VSTS repo dedicated to artifacts, to configure the repo follow the instructions to Add a Git repository to store custom artifacts and Azure Resource Manager templates for use in Azure DevTest Labs.

You can test the provision of the new machine creating a new VM in the DevTestLabs, the two new artifacts should show up in the artifacts section

Arm template

For the automation of the process capture the ARM Template for detailed instructions check View and save a virtual machine's Resource Manager template  (the sample with the artifacts configured is available here)

There are few elements that are modified from the template provided from the Azure Portal

A new expiration date parameter, it will be used to specify when the machine should be deleted automatically

A new variable of the hostDns with the resource group location and the domain of the machine

Modified parameter in the InstallWinRm artifact to pass the hostDns variable

And finally set the property "disallowPublicIpAddress": false in order to allow every VM to have a public IP address so VSTS can communicate with them using the WinRM port 5986 (if this property is not set the VMs will share the public IP address and will use NAT rules to allow access to the internal ports)

The ARM template should be committed to the same repo where the tests are.

Additional DevTestLab configuration

Use the My Secrets tab in the DevTestLabs to create a password for your VMs, it will create under the covers a KeyVault , check in your list of KeyVault the one with a Secret with the name you just provided, you will need the KeyVault name later for the automation

Visual Studio Team Services (VSTS)

The Variables look like this

There are two new variables added to it the RSSetupCredentials and the VMExpirationDate, those will be used to create the DevTestLab VM, the RSSetupCredentials  is marked as secret so it doesn’t show up in the logs, this variables will be set during the Get Password and Expiration Date script in the build tasks

The build tasks look like this

The following task have interesting configuration

Get Password and Expiration Date is a call to an Azure PowerShell Task with the the following content

$expirationDate=(Get-Date).AddDays(2).ToString("yyyy-MM-ddThh:mm:ssZ")
Write-Host "##vso[task.setvariable variable=VmExpirationDate]$expirationDate"
$RsSetupCredentials=(Get-AzureKeyVaultSecret -VaultName 'testlabc1043838' -Name 'rsSetupCredentials').SecretValueText
Write-Host "##vso[task.setvariable variable=RsSetupCredentials]$setupCredentials"

It sets the expiration date and the credentials for the VM and make it available for all the other tasks in the build, it gets the password from KeyVault, replace it with the name of the KeyVault from your DevTestLab environment

Create Azure DevTest Labs VM

It uses the parameters just created

Important to notice it uses the Build.BuildNumber as the name of the VM so every VM have a unique name, in order to make this work the build name is modified from the default using a dot to a dash $(date:yyyyMMdd)$(rev:.r) to $(date:yyyyMMdd)$(rev:-r) (it is available in the options tab in the build)

Get Lab Machine Parameters is a call to an Azure PowerShell Task with the the following content (the script is taken from Create an Azure RM template)

Param( [string] $labVmId)

$labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId

# Get lab VM resource group name
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Get the lab VM Name
$labVmName = (Get-AzureRmResource –Id

$labVmId).Name

# Get lab VM public IP address
$labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Get lab VM FQDN
$labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Set a variable labVmRgName to store the lab VM resource group name
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Set a variable labVMIpAddress to store the lab VM Ip address
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Set a variable labVMFqdn to store the lab VM FQDN name
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

The most important thing about that script ins the FQDN of the VM that will be used later to deploy the test agent

Deploy Test Agent using the variables created, https and enabling UI tests

Copy Files , it is copying the entire content of the repo from the agent to the VM, it can be changed to copy only the test bits or only the resources needed for your test

Run Tests, executes the test in the remote machine

The final task deletes the machine , it will not be executed in case that any of the test fails so the machine is available for 2 days for investigation.

A common ask from consultants and architects working with SQL Server Reporting Services is about capacity planning and how to validate that the environment proposed will meet the estimated workload, it is a simple question with a very complex answer because there are plenty of variables in an enterprise SQL Server Reporting Services deployment.

One of the tools we use in the development team is synthetic load generation using Visual Studio Load Tests. Simulating every detail of an interaction with the server is a daunting task, so we use synthetic workloads where we favor the flexibility of define different settings in the workload instead of an accurate 1:1 simulation of what will happen in the browser and in the native clients, the load generation is an abstraction that allows us to create workloads in the server in an agile way.

Nothing stops you of create your own set of load tests using the different tools that Visual Studio and other tools offers. However, you might find it challenging due the complexity of the different APIs and security features you will need to use in order to drive the workload.

Ladies and Gentlemen don’t hold your breath and let me introduce you to the Reporting Services Load Test project hosted in GitHub, we welcome you to try it out and contribute to it, this project take care of many or the challenges, although is not for the faint of heart as it have it’s own set of complexities, we have done our best effort in order to document how to use it and all that is written with the world acclaimed style of engineer prose in the project readme.

The project contains two sample workloads that we use in our development cycle, one called PaginatedLoad, it has a mix of paginated reports only, and MixedLoad has a combination of paginated, mobile and portal tests, you can also use the tutorials How to onboard a new Paginated Reports Scenario and How to onboard a new Mobile Reports Scenario to create your own workloads with your own reports.

In case you need to validate your topology but you don’t have any hardware, it contains an Azure ARM template that we use in our development cycle to bootstrap a minimal enterprise environment in Azure with the following machines

• Domain Controller
• SQL Server Engine to host the Reporting Services Catalog
• SQL Server Engine and AS Tabular to host Data Sources
• SQL Server installation with public DNS to configure Reporting Services

This project is very close to my heart as is something that we have had in the team for a long time but never had the chance to share it with the community, also was a challenging project as the code required a “little bit” of cleanup and changes to make it simpler (it’s still complex and it has it’s own personality and quirks as any good old seasoned project).

You might be thinking, well all that is good and fancy but what can I do with it besides overwhelming with requests my dear Reporting Services environment?

One of the scenarios is to validate that the environment that you are setting up will be able to support your estimated demand, remember that the workload is synthetic so is not at 1:1 mapping between user and test cases but is an approximation, basically you can take your existing reports, the usage pattern that you expect (from exports and rendering) and create a Load Test with them (see the tutorials and the existing load test samples in the solution).

Then you can take the Load Test and run it in your environment and monitor your CPU, memory and windows performance counters to figure out what are your bottlenecks. You can combine that with the metrics that Visual Studio Load Test will collect for every report and every scenario like:

• Passed Tests / Sec
• Failed Test / Sec
• Avg. Response Time

Among many others, and use them to figure out when your environment is not able to support the load consistently, for example the image below shows a view of the of the suite reports. The test/sec and the passed tests increased nicely along with the user load until a bottleneck is reached and then the avg. response time increases and the number of tests/sec drops dramatically.

This is just one example of the validation you can do with the suite. You can experiment with different work loads, step patterns, combination of tests (actions in the portal) and after you setup one, you only have to change the config file to point it to a different server and run the same workload again (either from Visual Studio Load Test on premises or in the cloud with Visual Studio Team Services on the cloud)

This posting is provided "AS IS" with no warranties, and confers no rights

Recently our team released the Reporting Services PowerShell Tools as a project to collaborate with the community, we had a lot more feedback and participation that we ever thought so we decided to push it a little further and publish it to the PowerShell Gallery.

We aren't by any means PowerShell experts and when we published the module we found that we should have run the PSSScriptAnalyzer , so we run it and fixed the issues but that will not scale as a manual task also I would like to automate the publishing to the gallery so is always in sync with the code in the repo.

Investigating around I found this great starting point in the https://ramblingcookiemonster.github.io/GitHub-Pester-AppVeyor/ blog post, it describes how to use AppVeyor for running unit tests with Pester, however I wanted something slightly different, my main goals are:

1. Provide static analysis using PSSScriptAnalyzer and show the results to the users submitting the pull request
2. After the PR is merged into main publish automatically to the PowerShell gallery

So I started by onboarding the GitHub repo to AppVeyor and created a New Project based on our repo, the procedure is pretty straightforward and AppVeyor has plenty of documentation so I'm not including any detailed instructions.

Onboarding the ScriptAnalyzer

First thing is to add the appveyor.yml file in our GitHub repo, my initials attempts failed , basically I wanted to install the PSScriptAnalyzer module but it failed with

Exception calling "ShouldContinue" with "2" argument(s): "The method or operation is not implemented."

At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:5908 char:8

+ if($Force -or $PSCmdlet.ShouldContinue($shouldContinueQueryMessag ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException

+ FullyQualifiedErrorId : NotImplementedException

Install-Module : NuGet provider is required to interact with NuGet-based repositories. Please ensure that '2.8.5.201' or newer version of NuGet provider is installed.

At line:1 char:1

+ Install-Module -Name PSScriptAnalyzer

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidOperation: (:) [Install-Module], InvalidOperationException

+ FullyQualifiedErrorId : CouldNotInstallNuGetProvider,Install-Module

Command executed with exception: NuGet provider is required to interact with NuGet-based repositories. Please ensure that '2.8.5.201' or newer version of NuGet provider is installed.

The solution is to install first the nuget package provider, the install section end up being

The next step is to produce a XML results file, I spend some time figuring out what would be the simplest schema and selected junit and then I used some magic string manipulation to get the results of the script analyzer into the testresults file

# Execute the script analyzer

$results = Invoke-ScriptAnalyzer -Path .\functions -Recurse | where severity -eq "Error"

# Format the results

$header = "<testsuite tests=`"$($results.Count)`">"

$body = $results | ForEach-Object {"<testcase classname=`"analyzer`" name=`"$($_.RuleName)`"><failure type=`"$($_.ScriptName)`">$($_.Message)</failure></testcase>"}

$footer = "</testsuite>"

$header + $body +$footer | out-file .\TestsResults.xml

# Upload results

$wc = New-Object 'System.Net.WebClient'

$wc.UploadFile("https://ci.appveyor.com/api/testresults/junit/$($env:APPVEYOR_JOB_ID)", (Resolve-Path .\TestsResults.xml))

# Fail if there are issues

if($results.Count -gt 0){throw "ScriptAnalyzer found $($results.Count) issues"}

That gives me this nice UI when the script analyzer finds any issue (in order to test the pipeline I removed the filter and allowed the warnings to show as test failures)

You can check the entire script in our repo appveyor.yml

Publishing to the PowerShell Gallery

I want to control the publishing process, I don't want every single commit to master to publish a new version of the module to the PowerShell Gallery, so I decided to use git tags in order to request a publish, basically when a new tag is added the continuous integration process will run the tests and if they pass it will use the tag label as the version to publish in the gallery, the general workflow is

1. Update the module manifest (.psd1) with the tag version
2. Publish to the PowerShell Gallery
3. If the publish is successful commit back to the repo the new module manifest (.psd1)

Interacting with the PowerShell gallery is based on a secret key they provide to use it in the Publish-Module cmdlet, in order to be used in your AppVeyor script you should encrypt it, the detailed instructions are available here https://www.appveyor.com/docs/build-configuration/#secure-variables

Also here are the instructions on how to interact with git from the AppVeyor script https://www.appveyor.com/docs/how-to/git-push/

One issue that I hit was that my git commands from powershell were treating the git console messages as errors, searching around found this workaround and implemented in the AppVeyor script, the deploy section looks like this.

# Deploy to Powershell Gallery only where there is a tag which will have the version number

$deploy = ($env:APPVEYOR_REPO_TAG -eq $true)

if ($deploy)

{

   git checkout master

   Write-Host "Starting Deployment tag $env:APPVEYOR_REPO_TAG_NAME"

   $moduleName = "ReportingServicesTools"

   $currentVersion = (Import-PowerShellDataFile .\$moduleName.psd1).ModuleVersion

   ((Get-Content .\ReportingServicesTools.psd1).replace("ModuleVersion = '$($currentVersion)'", "ModuleVersion = '$($env:APPVEYOR_REPO_TAG_NAME)'")) | Set-Content .\$moduleName.psd1

   Publish-Module -Path .\ -NuGetApiKey $env:galleryPublishingKey

   git config --global core.safecrlf false

   git config --global credential.helper store

   Add-Content "$env:USERPROFILE\.git-credentials" "https://$($env:access_token):x-oauth-basic@github.com`n"

   git config --global user.email "yourEmail@outlook.com"

   git config --global user.name "Your Name"

   git add ReportingServicesTools.psd1

   git commit -m "Automatic Version Update from CI"

   git push

}

For some unexplainable reason I wasn’t able to use the Update-ModuleManifest cmdlet so I did the manual replacing of the module version.

If you are interested in the entire deployment file it is available here in our repo appveyor.yml

Something I realized after I finished is that GitHub handle the tags as releases, which is perfect for my intentions, because now when we need to publish a new version we just create a release in GitHub and it will show up automatically as a release in the PowerShell gallery

Release in GitHub and in the PowerShell gallery

Finally many thanks to a fellow Microsoft engineer Sergei Vorobev who provided various tips around the entire process.

In SQL Server 2016 the team introduced Reporting Services mobile reports to SQL Server Reporting Services optimized for mobile devices and connected to on-premises data, with an assortment of data visualizations.

The mobile reports can be consumed using any mobile device (IPhone, IPad, Android, Windows 10) in the Power BI mobile app while you are connected to the corporate network where Reporting Services is hosted, however some of the users also want to consume the mobile reports outside of the corporate network just using the internet, in the past such scenario required the careful configuration of different firewalls , demilitarized zones (DMZ) and opening specific tcp ports , for instance this article cover the basics but usually you work with your IT specialists to deploy such configuration.

Recently one of my friends in the Active Directory team mentioned Active Directory Application Proxy , which show promise as an option to open the mobile reports to those users outside of the corporate network with a simpler solution, so I decided to give it a try during the weekend and see how it would work with Reporting Services (warning: every single step is very well documented for people that does a better job than me writing so mostly I’m just providing the links to the documentation that I used and providing specific details of my configuration)

The first thing that you need is an Azure Active Directory (AAD) configured and syncing with your Active Directory (AD) on premises, in my test environment I just followed the instructions from Integrating your on-premises identities with Azure Active Directory and voila I have my AAD with the users from my on premises AD.

The next step is to Enable Active Directory Application Proxy , just following the detailed instructions.

Now is time to Publish applications using Azure AD Application Proxy , you can provide any name and the internal URL that is used to access SSRS is your corporate network, you also should use the Passthrough preauthentication method.

You might be wondering why Passthrough and not Azure Active Directory as the documented instructions, well it as long story about how the different authentication methods have evolved from basic with your password traveling as clear text over the network, NTLM , Kerberos and the “modern” authentications protocols like OAuth for applications over the Internet, Reporting Services being primary an On Premises services supports Basic, NTLM and Kerberos out of the box, and the Power BI app for Reporting Services expects those authentication protocols so if you add something in the middle like Azure Active Directory authentication the application doesn’t know what to do, so for this configuration you need to use Passthrough to allow the mobile app to authenticate

After publishing the app you need to Assign users and groups to the application , previously I created in the on premises Active Directory a group called SSRSAccess so I can just add to it the users I would like to grant access to the service, I assigned this group to the newly created Jaime SQL Server Reporting Services Application.

Now in the Azure Portal if you click in the Application and in the option Configure you will see a section with the public URL of the endpoint, is your opportunity to customize it a little bit, in my case I just rename from what the portal automatically provided to mobile

Its time for the test, as is something I never tried I didn’t expect full functionality but the url should be a good start to see if the publishing worked, so I took the URL and pasted on my browser, that’s when you realize and a newbie in the AAD matters as I got the following error

Lucky for me the AAD documentation has a very detailed troubleshooting guide where I found “Go to the subscriber’s Active Directory Licenses tab and make sure that this user or user group is assigned a Premium or Basic license.” , that fixed my issue

You know is ready to work when you type your URL in the browser https://mobile-jaimetars.msappproxy.net/reports/ and you are able to see the new Reporting Services Portal

The next step is to configure the Power BI Mobile app with the URL and the credentials

Yes!!! Average Joe (ajoe) can now access his mobile reports from the Internet.

Limitations and Considerations

My main goal during the experiment was to try out Active Directory Application Proxy to provide access to the mobile reports, this is not an official recommendation is provided "AS IS" with no warranties and before you try this in your environment you should consult with your IT department about your policies to enable external access to corporate information.

You can also provide full Reporting Services Portal access exposing the URL of the server (https://ssrs-rs/) instead of just the portal (https://ssrs-rs/reports/) as I did, for that scenario you can even enable Active Active Directory as an PreAuthentication method and use two factor authentication and any other policy you have configured in your AAD, however there are few limitations to keep in mind:

• You need to type your credentials again after the Azure PreAuthentication
• Simple paginated reports and KPIs just works !!!
• The future is here , we have fixed this issue. I have found the Mobile Reports doesn’t render in the browser in this configuration , it’s something I will look in our code to fix it in the future.
• Check https://powerbi.microsoft.com/en-us/documentation/powerbi-mobile-oauth-ssrs/  The Mobile App would not work as it doesn’t know how to authenticate
• Subscriptions and other features that relies in the URL configured in Reporting Services might be affected as SSRS doesn’t know anything about the URL that you get from AAD which is totally different from the one configured in Reporting Services

There are plenty of other things you I haven’t tried like Publish applications using your own domain name, Single sign-on and conditional access

Recently we were investigating a case reported by one of the Reporting Services customers where he was able to render reports, but every time he tried to create a datasource he got the following error.

This is a very common scenario where the team has plenty of coverage during coding , testing and dogfooding, I was very surprised that it wasn’t working but you still could render reports and navigate the portal.

The next step is to check the logs (in a default installation would be in C:\Program Files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\LogFiles), something to be aware is that Reporting Services 2016 has introduced a new log file for the new portal , those logs start with Microsoft.ReportingServices.Portal for example Microsoft.ReportingServices.Portal.WebHost_06_19_2016_15_59_43.log, we still have the old logs for any operation that interact with the ReportServer , including calls to the SOAP endpoint, report execution and background operations.

The log was showing a 401 unauthorized error.

Microsoft.ReportingServices.Portal.WebHost!reportserverwebapp!11!06/19/2016-16:00:48:: e ERROR: [56x1bucj]: 
OData exception occurred: System.Net.WebException: The request failed with HTTP status 401: Unauthorized.
   at Microsoft.SqlServer.ReportingServices2010.RSConnection2010.SetConnectionProtocol()
   at Microsoft.SqlServer.ReportingServices2010.RSConnection2010.SoapMethodWrapper`1.ExecuteMethod(Boolean setConnectionProtocol)
   at Microsoft.SqlServer.ReportingServices2010.RSConnection2010.SoapMethodWrapper`1.ExecuteMethod()
   at Microsoft.SqlServer.ReportingServices2010.RSConnection2010.ListExtensions(String extensionType)
   at Microsoft.ReportingServices.Portal.Services.SoapProxy.SoapRS2010Proxy.<>c__DisplayClass41.<ListExtensions>b__40()

From the error is easy to identify that the Portal is calling the Report Server in order to retrieve the list of extensions available to create the datasource, but the mystery still remains, if possible to connect to the portal https://myazurevm.westus.cloudapp.azure.com/reports and is also possible to connect to the reportserver https://myazurevm.westus.cloudapp.azure.com/reportserver, so clearly the permissions are ok.

Next step is either to attach the debugger or to use a network monitor like wireshark or Microsoft Netmon and figure out what is going on the machine, lets try the network monitor

There is something fishy here, wireshark by default isn’t able to capture local traffic so seeing the call between the portal and the reportserver is interesting, also the source and the destination of the calls are from different IP addresses and the portal process and reportserver are in the same machine

Now lets check the authentication challenge / response for that 401 and looks like is trying to use NTLM (for a good reference on how does it work , check my favorite https://blogs.msdn.microsoft.com/chiranth/2013/09/20/ntlm-want-to-know-how-it-works/)

Reporting services setup configures different default authentication based on your selections on the setup (all of them detailed here https://msdn.microsoft.com/en-us/library/cc281253.aspx), I checked mine and was configured <RSWindowsNTLM /> which maps the response I observed in the network monitor and well you can’t impersonate when you are using NTLM, to rule out wasn’t another issue I tried the NOT RECOMMENDED option of enabling basic and everything started to work (also the credentials were traveling as clear text in the network so at least SSL is configured it is a configuration to avoid), other option for credentials delegation is to configure Kerberos properly but that is a beast that I’m not ashamed to confess I haven’t tamed (once in a while and after a lot of reading and experimenting works for me).

The real clue here is why the portal is trying to contact the report server in a different IP address, so lets check the Reporting Services Configuration Tool for the Report Server Web Service URL and the Web Portal URL

Here is the clue, the only available url for the Portal to talk with the Report Server Web Service is the azure public DNS name

There are two solutions for this issue

Easy Solution

Add all the assigned IP addresses to the Report Server HTTP URL

Advanced Solution

Use the same procedure documented for https://msdn.microsoft.com/en-us/library/cc281307.aspx, check for the step “Add the NetBIOS and Fully Qualified Domain Name (FQDN) for the host header to the list of BackConnectionHostNames stored in the Windows Registry”

The summary of instructions are

1. Add a new DWORD value in the registry path HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

Value name: DisableStrictNameChecking
Data type: REG_DWORD
Base: Decimal
Value: 1

2. Add a new Multi-String value in the registry path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Value name: BackConnectionHostNames
Data type: Multi-String
Value: ssrs20163.westus.cloudapp.azure.com

One of the Azure features I have in my list to try is the ARM templates and what better example than configuring SQL Server Reporting Services in a two machines configuration, one machine with Reporting Services and the second machine with SQL Server for the Reporting Services databases.

(Disclaimer: I work in the SQL Server Reporting Services Team , but this is a personal side project)

I tried to use as much of the existing infrastructure as possible so I took the existing SQL Server images in the azure gallery, I found that you can query those with the following Powershell commands

Get-AzureRmVMImageOffer -Location "westus" -Publisher "MicrosoftSQLServer" | Select Offer

Get-AzureRmVMImageSku -Location "westus"-Publisher "MicrosoftSQLServer" -Offer "SQL2014SP1-WS2012R2" | Select Skus

The first command return the list of available images and the second the skus available for those images.

Then I started authoring my ARM template using Creating and deploying Azure resource groups through Visual Studio article and the guidelines from Authoring Azure Resource Manager templates.

It uses extensively Desired State Configuration and the xSQLServer module.

All this end up in my git repo for Reporting Services ARM Templates , click on it to explore it, one of the templates documentation is below.

When it is done you will have SSRS available in the dns you specified in dnsNameForPublicIP , it will become something like

YourDNS.westus.cloudapp.azure.com/reports

You can either deploy it using the UI (see the big Deploy to Azure button below) or using powershell script provided in the git repo ,  you will need the template file locally and the parameters file to run that command the syntax is

.\Deploy-AzureResourceGroup.ps1 -ResourceGroupName 'YourResourceGroup' -ResourceGroupLocation 'westus' -TemplateFile '\Templates\SSRS-Catalog\AzureDeploy.json' -TemplateParametersFile 'ParametersSample.param.dev.json'

 

Create a new SSRS Server with a SQL catalog (2 Machines)

This template creates two new Azure VMs, each with a public IP address, it configures one VM to be an SSRS Server, one with SQL Server mixed auth for the SSRS Catalog with the SQL Agent Started. All VMs have public facing RDP and diagnostics enabled , the diagnostics is stored in a consolidated diagnostics storage account different than the vm disk

Click the button below to deploy

By Default it will create the SQL machines using the image SQL2014SP1-WS2012R2 and the Enterprise sku, the full list of available images and their SKUs can be obtained running

Get-AzureRmVMImageOffer -Location "westus" -Publisher "MicrosoftSQLServer" | Select Offer
Get-AzureRmVMImageSku -Location "westus"-Publisher "MicrosoftSQLServer" -Offer "SQL2014SP1-WS2012R2" | Select Skus

For example

For CTP Versions of SQL the only SKU available is Evaluation

It contains a modified version of xSQLServerRSConfig that supports machines that are non domain join and uses SQL authentication for connection SSRS with the database based on the DSC package https://www.powershellgallery.com/packages/xSQLServer/1.4.0.0.

It contains the DSC scripts from https://sqlvmgroup.blob.core.windows.net/singlevm/PrepareSqlServer.ps1.zip used by the Azure marketplace to create SQL Machines

This posting is provided "AS IS" with no warranties, and confers no rights

After a small adventure in a big data team I'm back in the Reporting Services team.

Everything is new and at the same times some things never change, but I found very quickly that SSRS is building the new portal with recent web technologies such as Angular and Typescript, check out the announcement here

I decided that I want to try to use Visual Studio code for modifying and debugging some of the new great portal features and I wasn't able to find any step by step guide to do it (I found how to debug node.js apps but not just browser apps), so I give it a shot and here are my results

Programs and basic setup

1. Install Node.js https://nodejs.org/en/

2. Install typescript https://www.typescriptlang.org/#Download

3. Install Visual Studio Code https://code.visualstudio.com/

4. Install TypeScript definitions manager https://definitelytyped.org/tsd/

5. Install the chrome debugging extension https://marketplace.visualstudio.com/items/msjsdiag.debugger-for-chrome

The easiest way to do it is to open the command palette (Ctrl+Shift+P) and type install extensions

6. Install typescript definitions for angular

Move to your application directory and execute

C:\Repos\VSCodeDebug>tsd install angular --resolve --save

7. Install the nodejs web server

C:\Repos\VSCodeDebug>npm install -g http-server

8. Start the nodejs web server and take note of the http port

C:\Repos\VSCodeDebug>http-server

Running and debugging

You can use your own app or clone my super simple demo app from here https://github.com/jtarquino/VSCodeDebug where I "typescripted" the demo in https://angularjs.org/ for databinding

1. Configure the task runner to compile typescript

Try to build (Ctrl+Shift+B )

it will show that no task runner is configure

 

Click in configure and it will take you to the task.json file

Comment out the Compiles HelloWorld.ts program task runner

Uncomment the second section , so you can use tsconfig.json for the parameters for the compiler

// A task runner that calls the Typescript compiler (tsc) and
// compiles based on a tsconfig.json file that is present in
// the root of the folder open in VSCode

Open tsconfig.json and ensure the sourceMap property is set to true, this will generate the sourceMap files which allows the degugger to map the javascript files with the typescript files

{
    "compilerOptions": {
        "sourceMap": true
    }
}

2. Setup the debug, press f5 to start the debugging,

First time will ask for the environment pick Chrome

It will open the file launch.json, there are two important elements here the url and the webroot

url should be updated to your start page in my case is index.html

Update the port to use the one that the nodejs http server show when started ,in my case 8080

webroot should be the root of your application, it could be wwwroot or just the current directory, for my case is the current directory which is .  (yes just a dot)

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch index.html",
            "type": "chrome",
            "request": "launch",
            "file": "index.html"
        },
        {
            "name": "Launch localhost with sourcemaps",
            "type": "chrome",
            "request": "launch",
            "url": "https://localhost:8080/index.html",
            "sourceMaps": true,
            "webRoot": "."
        },
        {
            "name": "Attach",
            "type": "chrome",
            "request": "attach",
            "port": 9222
        }
    ]
}

Go to the debug button in VScode and select "Launch Localhost with source maps"

3. Set breakpoints and run

Press f5, it will open Chrome and it will stop at any breakpoint defined by you (for some weird reason you have to click on refresh at least one time before Chrome stops in the breakpoint)

Also important to notice that is debugging in the .ts as expected (instead of the .js that you get out of the box)

I had a very slow power pivot report and wanted to identify which query was taking the time so I enabled the tracing

The trace is generated by default in your desktop, the trace is a SQL Profiler trace so you will need to use SQL Profiler to open it.

When is open, organize the columns by eventclass

Now filter the eventSubclass to 25 which is execute SQL

Now you can focus in Progress Report End event and check what TSQL is taking longer

I use multiple Excel PowerPivot models created in different workbooks by multiple people, sometimes I need to mash up them or simply create a single workbook with all the models so I can share it easily in my Office 365 site

I tried opening the PowerPivot add in and realized that there is not option to copy the tables of the PowerPivot model

I also looked around and didn’t find any evident way to do it.

After some experiments I realized there is a way although is not that evident.

1.  Open your workbooks (the source and the destination)

2. Create a Pivot table from the PowerPivot table you want to copy

3. Right click in the new sheet created and click copy (You need to add at leas one field from your table)

4. As you have open the two workbooks you can select from the Dropdown list your destination workbook

5. Excel will copy not only the sheet but also the model, you can go to your destination workbook and check that the new PowerPivot table is there along with the connections. You can delete the sheet from the destination workbook and you will keep only your model

This posting is provided "AS IS" with no warranties, and confers no rights

I created a WCF Service in Azure and started to use it, it started very simple but we added new features that need to be protected, so I started the journey of taking my simple WCF Service and configure it to use SSL and client authentication, one of the requirements was minimal downtime, so I need a transition period where both endpoints were available (Secure and Non-Secure) until I was sure that all the clients were configured properly.

I used as base this article “Using Certificate Based Authentication to Consume a Windows Azure WCF Service from SharePoint 2010” from MSDN and did a set of needed adjustments to make it work in my environment.

Configure the Server

1. Add the new certificate to the Web Role

2. Add the new SSL endpoint

With this we have a new SSL secured endpoint, but any client can use it

Now lets configure the service , to do so you need to modify the web.config, in my case I was using httpBinding, I added two bindings under <system.serviceModel> the NormalBinding to make explicitly the non secure endpoint and the new SecureBinding

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="NormalBinding" />
        <binding name="SecureBinding">
          <security mode="Transport">
            <transport clientCredentialType="Certificate" />
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>

And now set the binding configuration to my service, both of them the Secure and the Normal to ensure both are available

    <services>
      <service name="MyWebRole.MyService">
        <endpoint binding="basicHttpBinding" bindingConfiguration="NormalBinding" contract="IService" />
        <endpoint binding="basicHttpBinding" bindingConfiguration="SecureBinding" contract="IService" />
      </service>
    </services>

Under <Configuration> configure the SSL negotiation 

  <system.webServer>
    <security>
      <access sslFlags="SslNegotiateCert" />
    </security>
  </system.webServer>

You can try to debug or deploy the Service and is very likely you will hit my major issue

“The SSL settings for the service 'SslRequireCert' does not match those of the IIS 'None'”

To fix that you need to unlock the web.config, to do it modify the ServiceDefinition.csdef and add a task

  <WebRole name="BeaconServiceWebRole" vmsize="Small">
    <Startup>
      <Task commandLine="Startup.cmd" executionContext="elevated" taskType="simple">
      </Task>
    </Startup>

Create a Startup,cmd file in your web role and add this

%APPCMD% unlock config /section:system.webServer/security/access

Try to debug and deploy and should work

You will notice that those instructions are already in the article that I mention at the beginning, I guess the Azure SDK has changed since then and now you need to use the environment variable %APPCMD% to call the configuration, to be able to debug that I did a couple of things

• Add this to the Startup.cmd

%APPCMD% set config -section:system.webServer/httpErrors -errorMode:Detailed 

It will allow you to see the detail of the errors, which will help you to understand the underlying issue

• Debugging locally you can add logging to your startup.cmd commands so you can see if they are successful, the quick way is to send it to a file like

%APPCMD% unlock config /section:system.webServer/security/access >> C:\logging\unlock.log

With that information I was able to figure out that the unlock wasn’t being executed and found the new way to do it with the %APPCMD% variable

Configure the client

Modify the app.config or web.config of the client to add the new configuration, you will need a new behavior, binding configuration and update the endpoint to use https my config looks like this

  <system.serviceModel>
    <behaviors>
        <endpointBehaviors>
          <behavior name="CertBehavior">
            <clientCredentials>
              <clientCertificate findValue="REplacewihtyourownthumbprintXXXXXXXXXXXX"
                storeLocation="LocalMachine" x509FindType="FindByThumbprint" />
            </clientCredentials>
          </behavior>
        </endpointBehaviors>
      </behaviors>
      <bindings>
            <basicHttpBinding>
                <binding name="secureByCert">
                    <security mode="Transport">
                      <transport clientCredentialType ="Certificate" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
          <endpoint address="https://myservice.cloudapp.net/service.svc" binding="basicHttpBinding"
          bindingConfiguration="secureByCert" 
          behaviorConfiguration="CertBehavior" 
          contract="IService" name="securedEndpoint" />
        </client>
    </system.serviceModel>

For web sites running in IIS you need to ensure the user in the app pool have permissions , usually the IIS applications run under Network Service to grant permissions to that account:

1. Open MMC.EXE
2. Added the certificate snap-in for local computer
3. Locate your certificate
4. Right Click -> All Tasks -> Manage Private Keys
5. Add the <LocalMachine>\NETWORK SERVICE account and assigned Read rights.
   

Remove the Non Secure Endpoint

When all the clients are updated you can remove the non secure endpoint, to do that just remove the non secure endpoint

        <endpoint binding="basicHttpBinding" bindingConfiguration="NormalBinding" contract="IService" />

The new configuration will be , with only the secure endpoint available

    <services>
      <service name="MyWebRole.MyService">
        <endpoint binding="basicHttpBinding" bindingConfiguration="SecureBinding" contract="IService" />
      </service>
    </services>

To avoid any downtime you can publish this new configuration to Staging in Windows Azure and swap it , the details are here Staging an application in Windows Azure