Microsoft Project Server WebServices

We've just delivered a mini POC for a customer based around Microsoft Office Project Server where a number of the PSI methods were wrapped into new simple SOAP services.

Having not worked with MOPS before it was a bit of a learning curve for a one day project. Whilst the technical documentation from the Project SDK was pretty good there seemed to be a real lack of easy to find (and implement) steps on configuring the MOPS environment.

So, what did we learn.....

1) Not all web service Urls are the equal. There are two paths into the PSI web services, one through the SSP and the other through the Site. Grab the SSP version for your WSDL Web Reference and the Site (Litware in this case) for "Production" use.

http://epm2007demo:56737/ProjectServer_SSP/PSI/Project.asmx
http://epm2007demo/Litware/_vti_bin/psi/project.asmx

2) To get authorized access to the web service (and avoid 401's everywhere) you need to do a few things.

Setup the User or Service Account that will call the PSI Web Services:
(thanks to Stephen Sanderlin)

1) In SharePoint Central Admin, go to "Application Management" and click "Manage this Farm's Shared Services".
2) Hover over the SSP's name
3) Click the drop-down arrow that appears to the right of the SSP's name
4) Click "Edit Properties"
5) Scroll to the bottom of the "Edit Shared Services Provider" page
6) Enter the user's ID into the "Process Accounts with access to this SSP" box
7) Click the "OK" button

Setup your proxy to access the PSI Web Services using the correct credentials:

The credentials you use here should be the same ones you have setup in the previous step. Here (using the MOPS VPC) we used the farmadmin account.

Project p = new Project();

p.Url = " http://epm2007demo/Litware/_vti_bin/psi/project.asmx";
p.UseDefaultCredentials = false;
p.Credentials = new NetworkCredential(@"farmadmin", "pass@word1","epm2007demo");

3) Testing and debugging is pretty simple (much the same as any other MS development really). The real issue was making sure that the process of CheckOut, Edit, CheckIn and finally Publish was implemented to avoid having to go to the MOPS Queue and manually retrieve stuck jobs.

Also the "Publish" step was necessary to push the changes upto the Project centre and make them visible, one to check if your code looks right but you can't see any changes ;-)

Once we'd worked out the configuration and process steps the actual development was very simple and straight forward. Hopefully this will save a few of you searching the net for all these answers.

One to leave you with, download and use the Project 2007 SDK, it's got loads of really good technical development examples that should cover most eventualities.

Wordle is right!

Ok, I know Wordle has been around for a while now but I ran it through our website the other day and it's produced this beauty.

It seems to me that running this against your web copy is a great quick way to visualise the value proposition you're trying to promote.

"Venture Technologies delivering great solutions [to] companies" just about sums us up!

We've been awarded Microsoft Certified Partner status

Everyone at Venture Technologies has been working hard over the last 18 months in developing our relationship with our customers and Microsoft. It's now paid off with us being awarded the coveted Microsoft Certified Partner status in the Business Process and Integration Competency.

The vast majority of Venture Technologies' work is around the Microsoft Server platform and in particular Microsoft BizTalk Server which is why we're so excited about this award!

MSDTC Transaction Errors. What to check?

We've been working on a datacentre migration where we're moving several web applications over to a new virtual environment (VMware ESX Server) and everything had been running smoothly until we started to get this error a week or so ago.

Event Type: ErrorEvent
Source: AnApplication
Category: None
Event ID: 0
Date: 29/11/2007
Time: 15:39:33
User: N/A
Computer: ASERVER

Description:Message failed to import - moving to suspend queue: System.InvalidOperationException: An error occurred while enlisting in a distributed transaction.
Server stack trace: at System.Data.SqlClient.SqlInternalConnection.EnlistNonNullDistributedTransaction(ITransaction transaction) at System.Data.SqlClient.SqlInternalConnection.EnlistDistributedTransaction(ITransaction newTransaction, Guid newTransactionGuid) at System.Data.SqlClient.SqlInternalConnection.EnlistDistributedTransaction() at System.Data.SqlClient.SqlInternalConnection.Activate(Boolean isInTransaction) at System.Data.SqlClient.SqlConnection.Open()

Trawling Google shows a number of possibilities for this, most usually around incorrectly configured firewalls, DTC settings or connection strings however nothing had changed in our environment to prompt these errors.

After trying Microsoft DTCPing and verifying everything was working as expected we moved on to the DTCTester. DTCTester was failing with errors which we found a little bizarre as the DTCPing tools that tests connectivity was passing with flying colours.

The one thing that hadn't been on the check list on any if the support sites (that we'd found anyway) was the amount of machine resources required to support distributed transactions.

We hadn't changed any of the resource allocations to any of the servers since setting them up, the web servers had 2 vCpus + 2gB of RAM and the SQL 4 vCpus + 4gB RAM and they had been allocated fixed minimums in the VMware Virtual Infrastructure Client resource pools. Adding additional VMs into the mix had squeezed something in the ESX Server and started to cause us problems somewhere down the line. After shutting down a few VMs miraculously we were getting distributed transactions working again.

Anyway, if you've tried everything else and you're still having problems with you DTC failing make sure you've got plenty of welly behind your servers and you might just get rid of that pesky "An error occurred while enlisting in a distributed transaction" message.

BizTalk ESB AddNamespace Pipeline Component Bug

If you've not come across the ESB AddNamespace Pipeline Component it's really great for injecting a namespace into xml documents you have no control over.

We're using this component on a project at the moment to aid routing messages through the BizTalk Message Box. Having created a generic "AddNamespace Receive Pipeline" we're configuring the properties on the pipeline through the BizTalk Administration Tool for each of the receive locations.

Since we only want to add a default namespace, a'la xmlns="http://venturetechnologies.co.uk/schemas/ourdoc" there's no need to set the NamespacePrefix property, however if you leave it untouched (empty) you'll get an Null exception at run-time. To work around this simply enter a value in the property field, tab out back in and delete the value, "OK" the property editor and voila, no more errors.

If we get time we'll find a fix and post it up to the CodePlex site, but for now the workaround is quick and easy and doesn't pollute the ESB code base.

BizTalk 2006 on VMWare Workstation

A client I was working for wanted BizTalk 2006 running on VMWare Workstation 5. Easy I thought, so I installed Windows Server 2003 Std R2, SQL Server 2005 Ent + sp1 applied all hotfixes and service packs via Windows Update, followed the BizTalk install guide religiously but still couldn't get the BizTalk configuration to apply successfully.

The Basic configuration was failing with an SSO issue:

Failed to generate and backup the master secret to file: C:\Program Files\Common Files\Enterprise Single Sign-On\SSO0FAB.bak (SSO) Additional Information (0x80070005) Access is Denied.

After much head scratching and searching it appears to be a similar issue to that reported with Microsoft Virtual PC.


The work around to get the Basic Configuration applying correctly is pretty simple.

1. Un-configure the BizTalk installation using the option on the Wizard.
2. Delete the Databases that the un-configure didn't remove (SSODB + BusinessRulesdB) otherwise the config will fail again next time you try.
3. Create the SSO Administrators security group manually.
4. Add the installing user's account and the BizTalk Service account to this new group.
5. Reboot the VM
6. Re-run BizTalk Configuration and this time it should all work swimmingly.

Welcome to the Venture Technologies Company Blog

So what do we do? Well, to put it simply (and to save re-quoting our web site http://www.venturetechnologies.co.uk/) I like to think of us in the same vein as Venture Capitalists except that our "Capital" is Development Resource. We invest our technical skills in companies and entrepreneurs to help them get their new products and ideas to market.

The Venture Technologies Blog is going to be a place to let the world know some of the juicy 'ins and outs' of our investments as well as 'techie tit-bits' that we find in our day to day dealings with the Microsoft development platform.


Talking about the Microsoft development platform, our consulting business has really taken off in the last six months and we're spending an increasing amount of time working with companies who are implementing either Microsoft BizTalk Server 2006 or Microsoft Office SharePoint Server 2007. With both products having their own unique intricacies, I'm sure we'll build up a useful library of Do's and Don'ts that we will happily share with you.