|Custom Party Resolution in BizTalk 2013 R2||Friday 15th April 2016|
During migrating a BizTalk solution from 2006 R2 to 2013 R2 I encountered a problem with custom party resolution.|
The SDK provides a PartyResolver Pipeline component that essentially wraps up '[admsvr_GetPartyByAliasNameValue]' stored procedure in the BizTalkMgmtDb. This allows you to resolve a BizTalk Party based on whatever data you fancy.
This 'party' management changed in BizTalk Server 2010 to 'Trading partner management', which seems to add a couple of levels of nesting in and changes the configuration screens around. Most crucially, any custom properties you tap into the Party configuration screen get serialised and saved as a binary blob in the BizTalk database.
This means the stored proc above cannot query the field and nothing works. Argh. Luckily, you can still find the old screen, it's just buried a bit deeper.
A Party now has the concept of multiple Profiles. This is to allow enterprises with different divisions that do things differently to have a common parent and specific settings for specific things. It is in this we find the legacy screen. By default a profile will be created, you can edit the properties on this to add more properties - but again, this won't work. You need to go to the identities tab before you get the correct screen. Properties entered here can be used with the PartyResolver component.
|Sorry, there was a problem mounting the file.||Friday 1st April 2016|
I have recently encountered yet another useful Microsoft error. This time when trying to mount an ISO file on a Windows Server 2012 R2 server I was receiving:|
"Sorry, there was a problem mounting the file."
Super helpful again, thanks Microsoft. The generic error goes hand-in-hand with a vast number of causes - that Google will allude you to. None of these though helped me. A bit more useful is the error when trying to use the "Mount-DiskImage" PowerShell command:
"A required privilege is not held by the client."
After much rummaging around I finally stumbled upon the issue. An over-eager DBA who had the Group Policy settings updated to give a SQL service-account elevated privileges. Group Policy unhelpfully will only replace security settings on a computer, it will not allow you to add things in. So by specifying a service-account in GP it took out the default entries.
This particular instance it was "Perform volume maintenance tasks" found in your Local Security Policy under Local Policies / User Rights Assignment.
By default this entry just has the Administrators user group. Restoring this, forcing a gpupdate and rebooting the server resolves the issue.