BizTalk Server 2020 BAM Configuration: Could not load file or assembly Microsoft.SqlServer.SQLTask

Recently I wrote a blog post about BizTalk Server 2020 BAM Configuration: Microsoft SQL Server Integration Services (SSIS) is not installed on the local machine. This blog is the sequence of that one since the errors I faced on that installation went way belong to that error. And yes, Microsoft SQL Server Integration Services and SQL Server Analysis Services were installed on the SQL Server, and SQL Server Management Studio (SSMS) 18.4 was installed on the BizTalk Server box.

Nevertheless, while trying to configure BAM features, I was getting the following error message:

Could not load file or assembly ‘Microsoft.SqlServer.SQLTask, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.

Once I solve that one, I endup getting another one:

Could not load file or assembly ‘Microsoft.SqlServer.Management.IntegrationServices, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.

And another one:

Could not load file or assembly ‘Microsoft.AnalysisServices, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.

And another one:

Could not load file or assembly ‘Microsoft.AnalysisServices.Core, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.

And another one:

Could not load file or assembly ‘Microsoft.AnalysisServices.AdomdClient, Version=13.0.0.0?,Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified.

This was a kind of a nightmare of errors after errors!

Cause

This is something that always annoyed me since Microsoft decided to separate the SSMS from the default installation. So, on one hand, it is great that clients can update to a recent version of the tool. Still, on the other hand, it complicates specific previous simple tasks like performing the configuration of BizTalk Server features in special BAM features.

By design, the latest SSMS only includes the latest version of SSIS assemblies.

I have been using this SSMS 18.4 version in almost all my BizTalk Server installations. But also, in most of my recent installations, my clients didn’t want me to install BAM because they were not using this feature. The reason I use SSMS 18.4 version is because it was the latest version available before BizTalk Server 2020 was released.

I have tried to uninstall this SSMS version and install a previous one – 17.9.1 – to solve this issue, but by doing that, I got a ton of other problems with the based features of BizTalk Server like SSO and Runtime. So I decide to keep using SSMS 18.4.

Trying to find the correct version of the SSMS may be an inglorious Task.

I saw comments and suggestions to solve this issue that I would do in a BizTalk Server environment like:

  • Installing SSIS on the BizTalk Server machine and re-run BizTalk configuration
  • Installing SSDT (SQL Server Data Tools) full ISO on the BizTalk Server machine and re-run BizTalk configuration
  • or by installing the Client Tools SDK from SQL Server installation media on BizTalk machine and re-run BizTalk configuration – this was, in fact, a possible alternative

But again, this issue is related without a doubt with problems related to assemblies reference mismatch.

Solution

You have several solutions on the table to solve this issue. I endup deciding that the simple and fast way was to do Assembly redirect at the machine level.

To solve this problem by using Assembly Binding Redirection in the machine configuration file (Machine.config) you should change both:

  • 32-bit: c:WindowsMicrosoft.NETFramework[version]configmachine.config
  • 64-bit: c:WindowsMicrosoft.NETFramework64[version]configmachine.config

And use the following configuration.

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.AnalysisServices.AdomdClient" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
            <bindingRedirect oldVersion="13.0.0.0" newVersion="14.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.AnalysisServices" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
            <bindingRedirect oldVersion="13.0.0.0" newVersion="14.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.AnalysisServices.Core" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
            <bindingRedirect oldVersion="13.0.0.0" newVersion="14.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.SqlServer.ManagedDTS" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
            <bindingRedirect oldVersion="13.0.0.0" newVersion="14.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.SqlServer.SQLTask" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
            <bindingRedirect oldVersion="13.0.0.0" newVersion="14.0.0.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.SqlServer.Management.IntegrationServices" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
            <bindingRedirect oldVersion="13.0.0.0" newVersion="14.0.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>
  • Just to be on the safe side, you should add this configuration in both 32 and 64-bit in .NET Framework 2.0 and 4.0 machine configuration files.
  • If you are not sure about what is the version of the DLL, you should find the DLL on this path:
    • C:WindowsMicrosoft.NETassemblyGAC_MSIL<name>

The post BizTalk Server 2020 BAM Configuration: Could not load file or assembly Microsoft.SqlServer.SQLTask appeared first on SANDRO PEREIRA BIZTALK BLOG.

Azure Breakthroughs: Finding the Azure VM administrator username

Azure Breakthroughs: Finding the Azure VM administrator username

I usually use a range of different usernames to define as the administrator of my Azure Virtual Machines, and I have others that clients shared with me. So, you may be thinking, why are you accessing the Azure VM’s using the administration account and not an AD account? Typically, these are standalone development environments where I need permissions as administrator, so sometimes, this is the quick and easy way. We may argue if this is the best practice or not, but it is without a dought the fastest and easy way.

And today, one of my team members called me asking what was the password of user ABC (not the real username name) to access one of our Azure BizTalk Server Development VM’s because he was trying all possible variants and it was not able to log in. Unfortunately, I don’t remember all the VM administrator usernames I use to create our internal VM, so the first question I asked was not about the password but if he was using the correct username to access the machine. He was not sure about it neither.

So, the main question is: How can you quickly find the Azure VM administrator username of a specific machine?

There maybe be many ways to find this information. I will highlight here two of them that I normally use.

Option 1: Using the Azure Portal

  • Go to Virtual Machines services on your Azure portal.
  • Select the Virtual Machine that you want to find the username.
  • On the Virtual Machine property page, from the option tree, click on the Run command option from the Operations section.
  • On the Run command page, select RunPowerShellScript and them type Get-LocalUser on the PowerShell Script panel and click Run
  • The output will be a list of local user present on the machine mentioning what is the administrator.

Option 2: Using PowerShell

Another easy option is using a simple PowerShell script:

Get-AZVM -Name VM-NAME | Select-Object -ExpandProperty OSProfile

The output of that command will have the Administration username of that VM:

Download

THIS POWERSHELL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

You can download Finding Azure VM Administrator Username from GitHub here:

The post Azure Breakthroughs: Finding the Azure VM administrator username appeared first on SANDRO PEREIRA BIZTALK BLOG.

November 1, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS

November 1, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform and Azure iPaaS?

Integration weekly updates can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

Microsoft Announcements and Updates

Community Blog Posts

 

Videos

Podcasts

How to get started with iPaaS design & development in Azure?

  • Robust Cloud Integration with Azure
  • Microsoft Azure for Developers: What to Use When
  • Serverless Computing: The Big Picture
  • Azure Logic Apps: Getting Started
  • Azure Logic Apps: Fundamentals
  • Microsoft Azure Developer: Creating Enterprise Logic Apps
  • Microsoft Azure API Management Essentials
  • Azure Functions Fundamentals
  • Cloud Design Patterns for Azure: Availability and Resilience
  • Architecting for High Availability in Microsoft Azure

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

The post November 1, 2021 Weekly Update on Microsoft Integration Platform & Azure iPaaS appeared first on Hooking Stuff Together.