How many VMs and how much memory for a TRUE SharePoint 2013 Development Farm?

The TRUTH…you actually need at least 5 VMs to really do true development in SharePoint 2013:

1) Domain Controller – 2GB ( pointed out that on server core, this can be knocked down to 512MB)
2) SVR-SPWFE01 – 8GB
3) SVR-OWA01 – 8GB
4) CLIENT01 – 4GB
5) SVR-SPAPP01 – 8GB

Why? Domain Controller being separate is straight-forward. You need
a SharePoint instance for sure (SVR-SPWFE01), this can host the visual
studio for development of server and client side code. You need a OWA
instance because it won’t let you install on a SP instance. You need a
client machine because you have to install Visual Studio express for
Windows Phone development to do things with Push Notifications and mobile
programming.  And the last instance is for doing true Search
development with a multi-role search architecture.

If you don’t have these FIVE, you can’t do every single development
task one would need to do in SharePoint 2013. Trust me, I have already
tried to get it down and it just doesn’t work.

The one that really pisses me off, is the Client machine.  I don't understand why Microsoft chose to FORCE us to install Visual Studio Express to do Window Phone Development.  It is ridiculous to have to do that.  Its a PRIME example of why Windows Phone development hasn't taken off.  They haven't been serious about preventing any inhibitors to development.  They just haven't made it easy to train people in classrooms that need everything installed on a single machine (including Server and SharePoint, et all).  It's also stupid to expect people to go through the hassle of dual booting their machines and losing productivity just to do Windows Phone development.

Total of at least 24GB of memory to run a full development environment.

Go buy an IBM X-Series server now!
CJG

SharePoint 2013 – The parameter ‘token’ cannot be a null or empty string

This is a painful error that pretty much has zero results on google.  It happens the moment you try to get a context from a SharePoint redirect to your web application.  A quick google, there is a blog post for this that references something misconfigured in the Office 365 side:

http://social.msdn.microsoft.com/Forums/en-US/appsforsharepoint/thread/535f939f-63a6-4779-92fa-575322e6b46e

But there is something else going on.  If your version of Visual Studio and Office Developer tools does not match office 365 (which is on RTM now) you will get this error!  In my case, I had the RTM of Visual Studio 2012, but a back level of the Office Developer Tools. 

After updating all Development tools to RTM version this went away!  But note, the error will ALWAYS occur the first time you hit the HTTPS web application (the one where you click the exception for the certificate).  Try a second time and the token will actually exist and the app will run. 

Another error that will disappear is the dreaded (also reference this post for information on this error):

Microsoft.SharePoint.SPException: The Azure Access Control service is unavailable

These don't display in S2S configured applications (using Windows Auth) so these apps won't display these errors.

Chris

SharePoint 2013 – PowerPoint Conversion Service Application (conversion.svc) – UnauthorizedAccessException

If you run across this error you will find it in the event log when you try to execute a call to the PowerPoint Automation Service Application for a conversion request.  The error occurs because the application pool account that the service is running under doesn't have the needed permissions (ie, they weren't setup by SharePoint properly in Beta) to create directories here:

 C:ProgramDataMicrosoftSharePoint

If you look at the permissions on the directory, you see that Machine Administrators can do anything they like on this directory.  Bummer.  You now have to add the service account (or change the application pool to some other account that you already have given this access…like the Farm Account) for the PowerPoint Automation Service Application into the local machine administrators group.  That seems a bit much don't you think?

Hopefully it will be fixed in RTM,
Chris

SharePoint 2013 REST endpoints and more…Microsoft "REST SOA"

I'm yet again, building what will surely be the best development course on SharePoint 2013 (until someone copies it) in the world.  As part of the course, their is a module on making calls to SharePoint REST-ful services.  REST was available in SharePoint 2010 and could be made via calls to the various "svc" end points.  This wasn't ideal at all.  The reality is that no one in the SharePoint team likely knew much about how Facebook built their api(s).  Single end point, multiple paths in that single end point.  So let by-gones be by-gones…enter SharePoint 2013 and Microsoft with "ODATA".

The first thing to note.  The old REST end points (listdata.svc and excelrest.aspx, et all) are still there (with a few rare exceptions, backwards compatibility has always been a major strength of the SharePoint platform).  But in 2013, these are obsolete.  You should now use the new "/_api/" end point.  This end point will have many sub paths off of it to do what you need to do.  These include (from the public Microsoft TechNet Documentation):

  • site
  • web
  • search
  • contextinfo
  • lists

Some of the pages on technet allude to others (such as on this page which eludes to a BCS end point, but that really is BS…it don't exists ladies and germs).  Unfortunately, this documentation was based on earlier builds and is incorrect.  The end points have changed in the Beta release.  As part of building the course, I want a COMPLETE coverage of all the end points.  So I wondered where these end points might be defined.  Since _api seems to be a virtual directory, you would think it would be in IIS or the web.config files.  Nope:

So as an experienced developer, I knew the answer would be in the HttpModules.  Looking at the modules, only one really does everything and that is the SPRequestModule:


 

In reviewing the SPRequestModule code with Reflector.  You will find that deep down the "_api" directory actually gets mapped to client.svc.  An AH-HA moment!  In reviewing the code of the client.svc, you will find that there are two methods in this class:

 

The one we are interested in is ProcessRestQuery(), it contains a call to the ProcessQuery method of the RestService class which makes a call to ClientServiceHost.CreateServiceHost():

You will see a call to GeServiceHostTypes():

 

This is where things get interesting.  You will now see a call to the "microsoft.sharepoint.client/serverRuntime" entry in the web.config file:

Looking at this section in the web.config file, it points to a class called Microsoft.SharePoint.Client.SPClientServiceHost.  This class actually exists in the Microsoft.SharePoint.dll in SP15.  Looking at that class you will find a couple of interesting methods.  Mainly the GetRegisteredClientCallableProxyLibrariesFromSetupDirectory and its overrides.  It should really only have one method, but because of the beta, it has two.  If you're smart enough, you will be able to figure out why.  Looking at the non parameter based method, you see a call to "configclientcallable" directory.  It is rounding up all the "proxylibrary.*.xml" files.  This directory exists in {SPRoot}ConfigClientCallable.  In looking at this directory, you hit the JACKPOT!

It has several xml files.  If you open the files you will find a set of xml files that define pointers to ServerStubs:

 

Looking at one of the files (ProxyLibrary.stsom), you find a pointer to an assembly:

 

So let's find this ServerStub assembly…oh wait…dotNET 4.0 keeps the GAC in a new location (C:windowsmicrosoft.netassembly).  This is where you need to look.  You will only find three stubs…but wait…there are 14 files?!?  Yeah…There are 11 missing ServerStub files in Beta!!  Hint hint hint…you can figure out why their were two method calls above and what we will have at RTM when it comes to RESTful services.   Some good stuff for SURE, but here are two biggies:

  • Taxonomy
  • Translation

Now…is that where this post stops?  Hell no.  How does the API know about the actual URLS off of "_api"?  This is where Microsoft SharePoint Team did a great job!  I have used these patterns many times but this is the first time I have seen Microsoft implement them.  As such is the pattern with Microsoft…wait to see if everyone likes it, then implement it.  Of course, that doesn't win you market share (look at the fight with Apple), nor does it give you a marketing brand that is deemed "Innovative", but rather "Follower".  I digress. How does the SPClientServiceHost know what to respond too?  As part of building a ServiceHost, you have to build a ProxyMap.  This knows to map the path to the actual class (and its methods and properties of which you can call).  In order to do this, it actually looks at custom attributes of each of the loaded assemblies.  It looks for three assembly attributes:

  • UrlSegmentAliasMap
  • ClientNamespaceMap
  • MetadataProviderType

The most important and one you see most documentation about on TechNet (even though most of it is wrong) is the "UrlSegmentAliasMap".  This is not defined on the ServerStubs!  It is defined across multiple assemblies of SharePoint.  If you look at the Microsoft.SharePoint.dll, you will find these custom attributes:

 

  • web
  • site
  • lists
  • contextinfo
  • navigation
  • events

You will also see some "ClientNamespaceMap" attributes:

  • Microsoft.ShraePoint.BusinessData.MetadataModel.ClientOM
  • Microsoft.ShraePoint.BusinessData.MetadataModel
  • Microsoft.SharePoint.ApplicationPages.ClientPickerQuery

Each of these will have a mapping to a particular class in some assembly.  The clientnamespacemap ones are mainly to the ServerStub files.  The regular ones map to Object Model classes.  So then begs the question…now that I know ALL the REST api paths…how to I get the methods?  Looking at each of the pointed too classes, you will find an attribute on each method called "ClientCallable":

 

This means you can call this method in your REST api calls!  The parameters can be passed with the matching method parameter names in the REST service call!

So what does all this mean?  It means that the SharePoint team actually built something that can be dynamically scalable!  They can simply add these proxy xml files to point to stub assemblies, and/or add the custom attributes to methods that are ready to be exposed to our client side code with complete EASE.  This has to be one of the best flexible implementations of REST SOA (I am going to coin that phrase by the way).

You now have the power…do with it what you will.

Enjoy,
Chris