vCAC Upgrade to 6.1.1 broke WFStubBuildingMachine

Greetings,

We stood up a vCAC 6.0.1 proof-of-concept environment back in August.  We're in the process of deploying vRA 6.1.1 in an upper environment, but we still have the PoC environment.  We upgraded the PoC environment to 6.1.1 -- the software upgrades went smoothly with no issues.  After the upgrades were complete, we also addressed these issues:

Slow AD Login times -- we applied the fix detailed here:  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2090809

Our tenant was bit by the account lockout timebomb, which we fixed by following this:  http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2075011

We then went to deploy a VM from a tried and true blueprint, and all of our build attempts are failing on the WFStubBuildingMachine.  I can provide details and error codes if you think it would be helpful, but I'm hoping that somebody out there can provide some knowledge around what has changed around the execution of WFStubBuildingMachine in 6.1.1.

We have several vCO workflows and custom code packaged into WFStubBuildingMachine.  Much of the customizations in this workflow stub involve the Daily Hypervisor custom hostname plug-in (http://dailyhypervisor.com/vcloud-automation-center-vcac-5-2-custom-hostnaming-extension/), the Infoblox IPAM plug-in, and hand-offs between them.  Here's a brief description of what we have going in WFStubBuildingMachine:

1. The custom hostname plug-in constructs the hostname based on information provided by the vCAC catalog request.
2. A series of vCO workflows are launched within WFStubBuildingMachine to receive the new custom hostname along with network-placement information from the catalog, run some custom code to determine which Infoblox network to target, then reserve an IP/DNS record for the custom hostname.
3. The network placement information is returned back to vCAC.
4. Finally, there is logic to create a computer account in AD if the machine is being built from a Windows blueprint.

Again, it was a PoC, analogous to a movie set that is intended to be torn down after the film has been aired.  This assembly of custom code was rock solid in 6.0.1.  I'm struggling to find information that will help us zero-in on what exactly is breaking after the upgrade to 6.1.1.  Hopefully one of you geniuses can give us some information on what changed in 6.1.1 or some ideas on where to zero-in.  Absent that, it looks like we'll be reverse-engineering everything that went into WFStubBuildingMachine, and that could be a significant effort.

This is the error that the IaaS box is throwing:

Message: <?xml version="1.0" encoding="utf-16"?>

<boolean>false</boolean>

Workflow 'WFStubBuildingMachine' failed with the following exception:

System.MissingMethodException: Method not found: 'System.Data.Services.Client.DataServiceResponse DynamicOps.Repository.RepositoryServiceContext.SaveChanges()'.

   at DynamicOps.Cdk.Activities.SetMachineProperty.Execute(CodeActivityContext context)

   at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)

   at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Category: Error

Priority: -1

EventId: 0

Severity: Error

Title:

Machine: LBW01HCPAP306

App Domain: DynamicOps.DEM.exe

ProcessId: 2676

Process Name: C:\Program Files (x86)\VMware\vCAC\Distributed Execution Manager\DEM\DynamicOps.DEM.exe

Thread Name:

Win32 ThreadId:5636

Extended Properties:

Thanks in advance for your help!