How to check what BizTalk Server 2020 Cumulative Updates are installed in your Servers with PowerShell

How to check what BizTalk Server 2020 Cumulative Updates are installed in your Servers with PowerShell

I previously wrote several posts about how you can Check/Get a list of BizTalk Server Cumulative Updates installed in your machines for previous versions of the product:

Now it is time to update this script to BizTalk Server 2020.

Checking what CU is installed is not a difficult task to do, but without a doubt, it is one of the most annoying tasks to do as an administrator because, and once again:

  • you can do it manually by checking “Control PanelProgramsPrograms and Features” and then view the “Installed Updates”, try to find them in the list can be sometimes very confusing because they are not organized in a category BizTalk;
  • Or rely on tools like BizTalk MsgBoxViewer, which sometimes are not up to date, to check and provide that information;

Probably there are other ways, nevertheless, this simple task should be simple, extremely easy and fast to do, what you really want to know is what are the BizTalk Cumulative Updates installed like:

This is the list of BizTalk Server Cumulative Updates installed in this machine: BTS2020LAB01
- Microsoft BizTalk Server 2020 Cumulative Update 1

To check if the last Cumulative is installed or not.

PowerShell script overview

So how can we easily automate tasks? and reuse them whenever necessary and at the same time saving significant time for other tasks?

Using PowerShell is a good option. Windows PowerShell is a Windows command-line shell designed especially for system administrators and can be used by BizTalk administrators to help them in automating repetitive tasks or tasks that are time-consuming to perform manually.

This is a simple script that allows you to configure the template name of the cumulative updates, that will change from version to version, and will give you the list of all BizTalk Server 2016 cumulative updates installed on your server:

$keyResults = Get-ChildItem -path HKLM:SOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionUninstall -Recurse -ErrorAction SilentlyContinue | where { $_.Name -match $CUNameTemplate}

...

foreach($keyItem in $keyResults)
{
    if ($keyItem.GetValue("DisplayName") -like "*$CUNameTemplate*")
    {
        write-host "-" $keyItem.GetValue("DisplayName").ToString().Substring(0,$keyItem.GetValue("DisplayName").ToString().IndexOf(" Update")+9)
        #write-host "-" $keyItem.GetValue("DisplayName")
    }
}

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

Check what BizTalk Server 2020 Cumulative Updates are installed with PowerShell
Microsoft | GitHub

The post How to check what BizTalk Server 2020 Cumulative Updates are installed in your Servers with PowerShell appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Assessment: PowerShell to check what BizTalk Server 2016 Feature Packs are installed in your Servers got updated

BizTalk Assessment: PowerShell to check what BizTalk Server 2016 Feature Packs are installed in your Servers got updated

In the past, I release this PowerShell in order that any BizTalk Administrator to check and control which BizTalk Server Feature Pack was installed in your BizTalk environment. However, recently Niclas Öberg, another fellow “BizTalker” that I meet in London Integrate event warn me that my script didn’t recognize the existence of FP3… and he was correct

An alternative was to use BHM but the current version of BHM is also not checking for FP3 (only 1 or 2 – this limitation for sure will be fixed in next versions of BHM), you may get a warning messages saying that no CU or FP is installed, or you may get an FP2 warning messages like me:

BizTalk Server 2016 Feature Packs: BHM
Nevertheless, I have installed FP3 in my environment.

Of course, once again you can easily check this manually in the “Control PanelProgramsPrograms and Features” and then view the “View Installed Updates”, although this can be a very annoying task.

So, I decided to fix my PowerShell script and release a new version that will solve this problem. Now, if you run the script you will be able to receive the following output describing what FP was or is installed in your environment:

Microsoft BizTalk Server 2016 Feature Pack 1 is installed
Microsoft BizTalk Server 2016 Feature Update 2 with CU3 [KB4054819]LDR is installed
Microsoft BizTalk Server 2016 Feature Update 2 with CU4 [KB4077058]LDR is installed
Microsoft BizTalk Server 2016 Feature Update 3 [KB4103503]LDR is installed

The beauty of this script is that now it is prepared for detecting any other future PF that may be released by Microsoft, without the need for you to change the script.

...
    foreach ($Property in $key.Property) 
    {
        if ($Property -like '*Microsoft BizTalk Server 2016 Feature Update *') 
        { 
            $findF2 = 1
            Write-Host "$($Property) is installed"
        }
    }
...

This script follows the sequence of scripts that I release in the past to check what Cumulative Updates where installed in the machines.

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

Check which BizTalk Server 2016 Feature Packs installed with PowerShellCheck which BizTalk Server 2016 Feature Packs installed with PowerShell (2 KB)
Microsoft | TechNet Gallery

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk DevOps: Monitor your BizTalk environment using PowerShell – Monitoring BRE Policies Pending to be Deployed

BizTalk DevOps: Monitor your BizTalk environment using PowerShell – Monitoring BRE Policies Pending to be Deployed

After a tweet exchange with Mark Brimble a fellow “BizTalker” that I respect and admire, I realized that I had developed a PowerShell script some time ago to monitoring BRE Policies that could help him solve his problem. The initial question or need he was facing was:

  • How would you detect when there is no rules policy in a deployed state? I don’t know how many times I import a rule an forget to set it to deployed…

Monitoring BRE Policies Pending to be Deployed: problem

This is a common problem, and to be honest, I sometimes forget what is the correct state of a policy: Deployed or Published. (the correct answer is Deployed). And unfortunately, there isn’t a simple solution to solve this need and the solutions that I found was:

  • Using BizTalkFactory PowerShell Provider that nowadays come with BizTalk Server (“SDKUtilitiesPowerShell” folder)
  • Create my own monitor script – more work involved

Using BizTalkFactory PowerShell Provider is quite simple, but it has some limitations for what I would like to archive, for example, it only shows the policies that are bound to a particular BizTalk Application.

Monitoring BRE Policies Pending to be Deployed: BizTalkFactory PowerShell Provider

And I would like to know and have visibility to all of them because you don’t need to bind a policy to a BizTalk Application on the BizTalk Administration Console to use that policy.

And for that reason, I decide to create my own monitor script that I can easily change and optimize for my scenarios.

The problem I faced in the past was in fact quite similar to what Mark Brimble was describing, maybe with some small differences but the end goal is the same, so I decide to help him (at least try) and publish this PowerShell script.

The purpose of this PowerShell script is to:

  • Monitor BRE Policies and check if the highest version of a given policy is on Deployed state
    • If not notify someone (your BizTalk administration team);

So how can PowerShell help us?

With this script, you can be able to monitor your BizTalk Server BRE Policies, highest versions, that aren’t in the deployed state. Only if the script finds any non-compliance, an email notification will be sent.

Taking this sample:

Monitoring BRE Policies Pending to be Deployed: Policies Sample

The result will be a notification that includes two warnings:

  • Policy1 is in a non-compliance state because version 1.2 is not deployed
  • Policy2 is in a compliance state
  • Policy3 is in a non-compliance state because version 1.2 is neither published nor deployed (this is optional, but I choose to include in my monitoring script)

This script is a combination of a PowerShell script and a SQL Server Script that allows you to set:

  • Set your email notification settings:
#Set mail variables
[STRING]$PSEmailServer = "mySMTPServer" #SMTP Server.
[STRING]$SubjectPrefix = "MBV Notification Report -  "
[STRING]$From = "biztalksupport@mail.pt"
[array]$EmailTo = ("sandro.pereira@devscope.net")
  • And configure a SQL Server script, that in fact were the magic happens. The SQL Script will have the ability to check what rules are in a non-compliance state:
/****** Sandro Pereira & José Barbosa - DevScope  ******/
;with 
cteHist as (
        select h.* from [BizTalkRuleEngineDb].[dbo].[re_deployment_history] h
join (select strname, max(dttimestamp) as dttimestamp from [BizTalkRuleEngineDb].[dbo].[re_deployment_history] group by strname) q on h.strName=q.strName and h.dtTimeStamp=q.dttimestamp
),
ctetDeployed as (
        SELECT StrName, nMajor, nMinor, nStatus
                                                FROM   (
                                                   SELECT StrName, nMajor, nMinor, nStatus
                                                                , row_number() OVER(PARTITION BY StrName ORDER BY nMajor, nMinor DESC) AS rn
                                                   FROM   [BizTalkRuleEngineDb].[dbo].[re_ruleset]
                                                   ) sub
                                                WHERE  rn = 1
)
select * from ctetDeployed d
where nStatus = 0
or exists (select 1 from cteHist h  where h.strName=d.strname and bDeployedInd=0)

The following Windows PowerShell script is a fragment that will help us demonstrate the monitoring capabilities:

$mydata = invoke-sqlcmd -inputfile $sqlQuery -serverinstance $server

Foreach ($log in $mydata)
{
    #Create mail body content
    $mailBody += "..."
}

Here is example expected report output from running the Windows PowerShell script sample, if any of the BRE Policies are in an unwanted state.

Monitoring BRE Policies Pending to be Deployed: Report

Note: This type of script must be viewed as a complement to the tools mentioned above or used in the absence of them. The script should also be adjusted to your needs.

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

Special thanks to my coworker José Barbosa for helping me optimize the SQL Server script!

The script can be found and download on Microsoft TechNet Gallery:
Monitoring BRE Policies in your BizTalk environment with PowerShell (18.0 KB)
Microsoft TechNet Gallery

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk Server: Creation of Adapter WCF-SQL Configuration Store entries failed. Access denied.

BizTalk Server: Creation of Adapter WCF-SQL Configuration Store entries failed. Access denied.

This week while configuring and optimizing a brand-new BizTalk Server 2016 environment we got the following error message while trying to configure register the WCF-SQL Adapter in the BizTalk Server Administration console:

Creation of Adapter WCF-SQL Configuration Store entries failed. Access denied. See the event log (on computer ‘SQL-SERVER’) for more details.

Creation of Adapter WCF-SQL Configuration Store entries failed

(sorry the picture quality, it was taken with my cell phone)

Despite I was a member of BizTalk Administration group, I didn’t have remote access to the SQL Server machine that was managed by another team so I couldn’t go there to check it out. Nevertheless, I reach that team (SQL and sysadmins) already with a possible solution that it turned out to be correct.

Cause

Many of the times these types of issues indicate or lead us to believe that there are problems associated with MSDTC. Or is not properly configured, Windows Firewall may be blocking DTC communications or in HA environment’s SSO is not clustered and may be offline.

All these possibilities should be investigated. However, if any of the points mentioned above were, for this particular case, a probable cause for this problem, it should have already manifested itself when the team pre-installed the environment and they did install the environment without encountering any problems.

The only difference between the installation and now my configuration was that these tasks were made by different users!

It is important to mention that, the user that is trying to registering an Adapter using the BizTalk Server Administration Console, need to have permissions to the SSO Database in order to register its properties so that he can store and retrieve the properties at design time and runtime.

And that is one of the reasons for why the “BizTalk Server Administrators” group should be a member of the “SSO Administrators” group.

BizTalk administrations are responsible for configuring all the components of BizTalk and many of them need to interact with SSO Database.

The people/team that was responsible to install BizTalk Server, they were members of BizTalk Server Administration, SSO Administration and some of them System Administrations and that was the reason why they didn’t get this problem or similar problems. The reason for the problem I faced was because:

  • My user was a member of BizTalk Server Administrators and local admin only. But the BizTalk Server Administrators wasn’t member of SSO Administration group.

Solution

To solve this problem, you may have two options:

  • Add my user to the SSO Administrators group.
    • Not recommended because in my opinion is more difficult to manage user access rights if you add them to each individual group.
  • Or add the “BizTalk Server Administrators” as a member of the “SSO Administrators” group.

After my user or the “BizTalk Server Administrators” group was added as a member of the “SSO Administrators” group, I was able to register the adapter.

Note: this problem can happen with any adapter you are trying to register.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

How to check what BizTalk Server 2013 Cumulative Updates are installed in your Servers with PowerShell

How to check what BizTalk Server 2013 Cumulative Updates are installed in your Servers with PowerShell

To finalize this series of posts about how to check what BizTalk Server <version> Cumulative Updates are installed in your Servers with PowerShell:

We just need to talk about BizTalk Server 2013 to cover the last 4 versions of the product. And I know some environments that still are running in this version, for this reason, it is still a valid and quite useful script.

This script is very similar to the script that I created for BizTalk Server 2010 because, in earlier versions, such as BizTalk Server 2010 and 2013, there were dedicated versions for BizTalk Server and BizTalk Adapter Pack. This has changed since BizTalk Server 2013 R2 where Microsoft decide to create Cumulative Updates for BizTalk Server, Adapter Pack, and Accelerators in a single resource and part of a single download.

PowerShell to check what BizTalk Server 2013 Cumulative Updates are installed in your Servers with PowerShell: This is a simple script that allows you to configure the template name of the cumulative updates, that will change from version to version, and will give you the list of all BizTalk Server 2013 cumulative updates installed on your machine:

This is the list of BizTalk Server 2013 Cumulative Update installed in this machine: BTS2013LAB01 
- Microsoft BizTalk Server 2013 CU1 
- Microsoft BizTalk Server 2013 CU2 
 
This is the list of BizTalk Server 2013 Adapter Pack Cumulative Update installed in this machine: BTS2013LAB01 
- BizTalk Adapter Pack 2013 CU1

The sample script (the link to the full script is available at the end of this post):

#Name template for BizTalk Server CU's for BizTalk Server 2013 (normally they are "Microsoft BizTalk Server 2013 CU#") 
$CUNameTemplate = 'Microsoft BizTalk Server 2013 CU' 
 
#The Wow6432 registry entry indicates that you're running a 64-bit version of Windows. 
#It will use this key for 32-bit applications that run on a 64-bit version of Windows. 
$keyResults = Get-ChildItem -path HKLM:SOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionUninstall -Recurse -ErrorAction SilentlyContinue | where { $_.Name -match $CUNameTemplate} 
 
if($keyResults.Count -gt 0) 
{ 
 write-host "This is the list of BizTalk Server 2013 Cumulative Update installed in this machine: $env:computername"
} 
else
{ 
 write-host "There is the no BizTalk Server 2013 Cumulative Update installed in this machine: $env:computername"
} 
 
foreach($keyItem in $keyResults) 
{ 
 if ($keyItem.GetValue("DisplayName") -like "*$CUNameTemplate*") 
 { 
 write-host "-" $keyItem.GetValue("DisplayName").ToString().Substring(0,$keyItem.GetValue("DisplayName").ToString().IndexOf(" CU")+4) 
 } 
} 
 
... 
 
#Name template for BizTalk Server Adapter Pack CU's for BizTalk Server 2013 (normally they are "BizTalk Adapter Pack 2013 CU#") 
$CUNameTemplate = 'BizTalk Adapter Pack 2013 CU' 
 
#The Wow6432 registry entry indicates that you're running a 64-bit version of Windows. 
#It will use this key for 32-bit applications that run on a 64-bit version of Windows. 
$keyResults = Get-ChildItem -path HKLM:SOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionUninstall -Recurse -ErrorAction SilentlyContinue | where { $_.Name -match $CUNameTemplate} 
 
...

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

Check all BizTalk 2013 Cumulative Updates installed in server with PowerShell (3 KB)
Microsoft | TechNet Gallery

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira