My disk folder structure is like this:

Similar for \Cust2
Similar for \Cust3 etc

I was looking for a sample 210 EDI Invoice to use in testing; and I wanted the most recent ones.

It turns out you can put a wildcard in the variable passed on the -Path parameter. In that case, I don’t really need the -Recurse option, but I included it anyway (just in case someone created additional subfolders).

$Startpath = "D:\Application\DEV\*\Outbound\210"

#If you just want THE Most Recent File: 
#$latest = Get-ChildItem -Recurse -Path $Startpath | Sort-Object LastAccessTime -Descending | Select-Object -First 1 
#Write-Host "Latest= $($lastest.Fullname)" 

#Most recent 12 files (or whatever number you chose in the -First ## parameter) 
$latestFiles = Get-ChildItem -Recurse -Path $Startpath | Sort-Object LastAccessTime -Descending | Select-Object -First 12
Write-Host "Outbound Latest 12 files" 
foreach ($file in $latestFiles) 
   Write-Host $file.FullName

Use the .FullName property to show the complete folder name in the results.

Any time you use the BizTalk WCF Service Publishing Wizard, it creates an IIS website with various content, including a “Temp” directory. The Temp directory has two entries:
1) BindingInfo.xml – can be used to create a Receive Port and Receive Location tied to your published web service
2) WcfServiceDescription.xml – this is the one we are going to discuss

I found this process described in this blog: Republishing BizTalk WCF Services. Also see How to Modify WCF Services previous published

You can run: BtsWcfServicePublishingWizard.exe /WcfServiceDescription=”your_WcfServiceDescription.xml”

The process is far from perfect. But it will restart the publishing wizard and on some of the screens, it will show you the same parameters. I noticed that the radio button on the screen that asks if your are publishing an orchestration or a schemas was not correct. And when you get to the screen that asks for the target namespace, the original value is not preserved and you have to re-paste it.

This could save you a lot of time, if you had a lot of services and operations in published together to the same website.

If you come to a site, and you find something has already been published, then you might have to add to it, or republish it. This can happen, for example, if you change the schema (add, removing, renaming elements and attributes).

<?xml version="1.0" encoding="utf-16"?>
<WcfServiceDescription xmlns:xsi="" xmlns:xsd="" Name="BizTalkWcfService" TargetNamespace="http://Sample.Integrations/" xmlns="">
  <LocationSettings Location="http://localhost:8081/Internal" Overwrite="true" AuthAnonymous="true" />
  <ApplicationSettings CreateReceiveLocations="false" ApplicationName="" />
  <AdapterSettings AdapterName="WCF-BasicHttp" />
  <MetadataSettings EnableMetadata="true" MetadataOnly="false" ReceiveLocationName="" />
    <WcfService Name="Internal">
        <WcfOperation Name="Outbound210Service" Flow="RequestResponse">
            <WcfMessage Name="Request" Direction="Input">
              <WcfMessageType Category="XsdType" TypeName="Sample.FrontEnd.InvoiceOut.Schemas.Legacy_Outbound210_Canonical" AssemblyName="Sample.FrontEnd.InvoiceOut.Schemas, Version=, Culture=neutral, PublicKeyToken=2393c33936991560" AssemblyLocation="C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Sample.FrontEnd.InvoiceOut.Schemas\v4.0_1.0.0.0__2393c33936991560\Sample.FrontEnd.InvoiceOut.Schemas.dll" TargetNamespace="http://Sample.Integrations/" RootName="Outbound210" IsAnyType="false" IsEnvelope="false" />

Whatever you specify for the WcfOperation, should have a corresponding service file. For example, Outbound210Service above, relates to OutboundService210.svc file. The WcfMessageType gives you the TypeName and AssemblyName of the schema that was published. The Targetnamespace attribute on the root element tells you the target namespace that was used.

To create a request-only (or one-way) webservice in BizTalk using the WCF-Service-Publishing-Wizard can be a little confusing at first.

After the first couple of screens, the wizard shows the screen below

You cannot delete the Response message. What you have to do is delete Operation1, then right click on the Service, select “Add Web method.”, then select “One-way” (instead of “Request-Response”, which was the original default.

Then you will have a one-way operation with only a Request method.

Other notes: Rename Service1 to some more appropriate name. It will create a file called xxxxxx.svc when the publisher has completed.
You can then add additional services if you want.

I’ve been doing a lot of “forensic” research on converting old systems lately. Sometimes I need to look at hundreds of ports at once, and opening each one separately to check the map is way to slow!

There are several joins required. The actual mapname is in the more generic bts_item table. You can get there by joining bt_MapSpec.

use BizTalkMgmtDb
select app.nvcName,
       sp.nvcName as SendPort, 
       item.Name as MapName,
  from bts_sendport sp 
inner join bts_sendport_transport spt on spt.nSendPortID = sp.nID and spt.nTransportTypeId is not null 
inner join bts_sendport_transform spMap on spMap.nSendPortID = sp.nID 
inner join bt_MapSpec ms on = spmap.uidTransformGUID 
inner join bts_item item on ms.itemid = 
inner join bts_application app on sp.nApplicationID = app.nID 
where sp.nvcName like '%210%'
order by app.nvcName, sp.nvcName 

select app.nvcName,
       rp.nvcName as ReceivePort, 
       item.Name as MapName,
from bts_receiveport rp 
inner join bts_receiveport_transform tr on tr.nReceivePortID = rp.nID 
inner join bt_MapSpec ms on = tr.uidTransformGUID 
inner join bts_item item on ms.itemid = 
inner join bts_application app on rp.nApplicationID = app.nID 
where rp.nvcName like '%210%'
order by app.nvcName, rp.nvcName 

This program uses a mix of Object Explore Model (ExplorerOM) and BizTalk Provider for Powershell
to delete Send/ReceivePorts that match certain naming conventions.

We were refactoring an application and re-adding ports under a different application, so needed a script to delete the old pots.

If you run this script, I do of course suggest you run it once with the Delete Statements commented out!
Recode the selection criteria as needed for your purposes.

Parts of code from examples here:

#=== ===#
#=== Delete the receive port named “My Receive Port” ===#
#=== ===#
Function DeleteSendPort ($sendPortName)
$receivePort = $catalog.ReceivePorts[$sendPortName]

if ($receivePort -ne $null)

#=== Try to commit the changes made so far. If the commit fails, ===#
#=== roll back all changes in the trap handler. ===#

Function DeleteReceivePort ($receivePortName)
$receivePort = $catalog.ReceivePorts[$receivePortName]

if ($receivePort -ne $null)

#=== Try to commit the changes made so far. If the commit fails, ===#
#=== roll back all changes in the trap handler. ===#

#=== Main Script ===#

#=== Make sure the ExplorerOM assembly is loaded ===#

[void] [System.reflection.Assembly]::LoadWithPartialName(“Microsoft.BizTalk.ExplorerOM”)

#=== Connect to the BizTalk Management database ===#

$Catalog = New-Object Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer
$MyBTSQLServer = “.” #substitute your SQL server name here
$Catalog.ConnectionString = “SERVER=$MyBTSQLServer;DATABASE=BizTalkMgmtDb;Integrated Security=SSPI”

#=== Register a trap handler to discard changes on exceptions ===#
#=== Execution will continue in the event we want to delete the ===#
#=== receive port. ===#

$Script:NoExceptionOccurred = $true
$Script:NoExceptionOccurred = $false
“Exception encountered:`r`n”; $_; “`r`nDiscarding changes and continuing execution so we can attempt to clean up the receive port…`r`n”

#=== Create the new receive port ===#
#Write-Host “`r`nAttempting to create `”My Receive Port`”…”

# used on EDI1 to get lists of TRLG send/receive ports related to 204/990
# and create CSV file
$showDate = Get-Date -DisplayHint Date
Write-Host “Started at $showDate”

Add-PSSnapIn -Name BiztalkFactory.PowerShell.Extensions #NOTE: Must be in 32-bit version of Powershell to use this SnapIn
#New-PSDrive -Name BizTalk -Root BizTalk:\ -PsProvider BizTalk -Instance EDI1-BTSDB2014\DB04 -Database BizTalkMgmtDb

Write-Host “— SendPorts —”
cd “Biztalk:\Applications\Echo.BSSR.Surface\Send Ports”
$SendPorts = Get-ChildItem
ForEach ($SendPort in $SendPorts)
#Write-Host $SendPort.Name $SendPort.Status
if (
($SendPort.Name.Contains(‘204’) -and $SendPort.Name.ToUpper().Contains(‘OUT’)) -or
($SendPort.Name.Contains(‘990’) -and $SendPort.Name.ToUpper().Contains(‘IN’))
## two formats of SendPorts spOutbound204XXXX and spSurfaceXXXoutbound204
Write-Host “Delete SendPort $($SendPort.Name)”


Write-Host “— Receives —”
cd “Biztalk:\Applications\Echo.BSSR.Surface\Receive Ports”
$ReceivePorts = Get-ChildItem
ForEach ($ReceivePort in $ReceivePorts)
#Write-Host $ReceivePort.Name
if ($ReceivePort.Name.Contains(‘990’) -and $ReceivePort.Name.ToUpper().Contains(‘INBOUND’) )
Write-Host “Delete ReceivePort $($ReceivePort.Name )”


$showDate = Get-Date -DisplayHint Date
Write-Host “Completed at $showDate”

If you try to delete an application or a SendPort, you might find that SendPort is used on an EDI Trading-Partner (party).
There is no easy xref in BizTalk to show you which party might be tied to that send port. Usually the naming conventions will help, but not always.
This SQL query gives you the cross-reference.

USE BizTalkMgmtDb

   party.nvcname [PartyName],
   application.nvcDescription [Application],
   sendport.nvcname [SendPort]
FROM bts_sendport sendport
INNER JOIN bts_party_sendport partysendport ON partysendport.nsendportid = sendport.nid
INNER JOIN bts_party party ON partysendport.npartyid = party.nid
INNER JOIN bts_application application on application.nid = sendport.nApplicationID 
ORDER BY party.nvcname,  sendport.nvcname

You can list the cmdlets yourself with this command:

<pre>Get-Command | where { $_.ModuleName -like "BizTalk*" } 

But here is a convenient list in text format:

CommandType Name
———– —-
Cmdlet Add-ApplicationReference
Cmdlet Add-ApplicationResource
Cmdlet Deploy-Policy
Cmdlet Disable-ReceiveLocation
Cmdlet Enable-ReceiveLocation
Cmdlet Enlist-Orchestration
Cmdlet Enlist-SendPort
Cmdlet Enlist-SendPortGroup
Cmdlet Export-Application
Cmdlet Export-Bindings
Cmdlet Export-Policy
Cmdlet Get-ApplicationResourceSpec
Cmdlet Get-TrackedMessageInstance
Cmdlet Import-Application
Cmdlet Import-Bindings
Cmdlet Import-Policy
Cmdlet Remove-ApplicationReference
Cmdlet Restart-HostInstance
Cmdlet Resume-ServiceInstance
Cmdlet Set-DefaultApplication
Cmdlet Start-Application
Cmdlet Start-HostInstance
Cmdlet Start-Orchestration
Cmdlet Start-SendPort
Cmdlet Start-SendPortGroup
Cmdlet Stop-Application
Cmdlet Stop-HostInstance
Cmdlet Stop-Orchestration
Cmdlet Stop-SendPort
Cmdlet Stop-SendPortGroup
Cmdlet Terminate-ServiceInstance
Cmdlet Undeploy-Policy
Cmdlet Unenlist-Orchestration
Cmdlet Unenlist-SendPort
Cmdlet Unenlist-SendPortGroup


It is also surprises me that you have to run a commandlet (like Disable-ReceiveLocation myRcvLoc) rather than calling a method on an object (such as myRcvLoc.Disable).

What seems to be missing from the list above are commands to remove items (or to create new ones).

Here are some Powershell scripts that use the ExplorerOM (Object Explorer) to do so:

Or to remove send ports, you can still do:

   cscript RemoveSendPort.vbs "My Business Send Port"