When is a BDC not a BDC?

After standing up my SharePoint 2013 farm, I thought “Awesome!, time to try connecting some of the 2013 Service Apps to my 2010 Farm”. It’s fully supported, right? I spun up the trust between the farms, and began connecting the 2013 Service Apps to my 2010 farm. After each one was connected, I dropped the 2010 Service App.

Everything seemed to be working, but then an issue with the BDC surfaced. It appears that you cannot create a new BDC model, or edit an existing one, if your content is still on 2010. I asked Microsoft about this, seems to be a “Working as designed” kind of thing. You can consume existing BDC models from the 2010 farm, just not change or create new ones in Designer. So, like me, if you brought your 2010 BDC database over and used it to create the 2013 BDC Service App, it’ll work, but no editing.

So, if you’re out there trying this like I did, and the BDC isn’t working, you’re not crazy (well, you might be crazy, but not about the BDC). No word if this will be fixed, or even if Microsoft believes it’s broken. Guess you’ll have to keep that 2010 BDC service around until you migrate your content to 2013.

(And please, let’s not have the BCS vs BDC argument…)

UPDATE: Microsoft may or may not have confirmed that this is working as designed. I have been told that the new 2013 BDC uses oAuth to communicate while created External Content Types. Guess they didn’t think of 2010 farms consuming the 2013 BDC. Soooo, it won’t work.

Testing Webapps On Each SharePoint Server

I love single line PowerShell commands. Scripts can be boring, but it you can condense everything down to a single line, you sir, rock.

If you’re running a multi-server farm and using a load-balancer to handle getting the web requests to a Front End servers, you’ll sometimes (always) really like to know if the webapps are responding correctly on each server. If you’re like me, you place self-referencing host file entries on each server for each Web Application. No sense in having the servers send WFE request back to the load-balancer. And, magically, that’s a pre-requisite for this PowerShell command running. Without the host file entries on each server, the web requests will just go to the load-balancer, and you’ll never figure out who’s working and who’s not.

Log on to each of your SharePoint servers and fire up the handy-dandy SharePoint Management Console. Once you’re there, fire off this command:

Clear-Host;Get-SPWebApplication | Select -expand URL | %{$wa= $_;$request = [System.Net.WebRequest]::Create($_);$request.Timeout = 30000;$request.UseDefaultCredentials = $true;Try{$webcall = ($request.GetResponse());Write-Host "Site:$($webcall.ResponseUri) -- StatusCode $($webcall.StatusCode)";Write-Host "`r"} Catch [system.exception] {Write-Host "$wa Failed -- $($error[0].Exception.Message)";Write-Host "`r"}}

This will pull each URL from SharePoint and spin up a web request and show you the feedback.

Note: You may need to adjust the timeout variable in the web request if your app pools have spun down and they need longer than 30 seconds to come back up.

Hope it helps!