Author: givenscj

Posted on

Project Server 2010 – Waiting For Resources

I ran into this interesting state in project server last week and was able to resolve it this morning.  You may find that the timer job never executes itself..why?  Have no clue!  Especially since we already ran it three times previously and it always worked!

So I figured a way to successfully fire it manually from PowerShell:

$job = get-sptimerjob -id 4d9b0bd6-2919-4256-b030-c9d50c168e57
$wa = get-spwebapplication https://projects.contoso.com
$job.Execute($wa.id)

Keep in mind that rather execute in the owstimer process it will run as the current PowerShell user.  That user must have access to the database server to apply security and create databases.

Enjoy!
Chris

Posted on

The Azure Access Control service is unavailable.

Lovely error right?  You can spend a lifetime trying to figure out why you can't get rid of this error.  But that's what community is for!  After writing my own OAuth apps to hit the SharePoint AppsSTS (appssts.svc), I finally know why this error occurs!

Turns out that O365 SharePoint Farms have a special Service Application installed.  This service application is not available to us mere mortals with Beta version of SP2013 running on-premise.  The service application is called "Azure Access Control Service Application".  It has a corresponding Proxy that goes with it.  When your SharePoint App code executes, it makes a call to this ACS proxy.  If it doesn't find the existance of one of them in your Farm, it fails with a null reference, and then you get the "The Azure Access Control service is unavailable." error. 

What does the proxy do?  It actually will grab the Azure EndPoint for OAuth2 and do the delegation calls.  You can see this xml document here:

https://accounts.accesscontrol.windows.net/metadata/json/1

Now you may be thinking…can I trick it?  Well, even if you could (which you can't), notice the "Location" fields in the SharePoint endpoint below.  Doing the same endpoint call in SharePoint, you will see that those "location" fields are not populated so you couldn't do it anyway!

http://intranet.contoso.com/_layouts/15/metadata/json/1

Nothing you can do about it with an onpremise installation of SharePoint 2013.  Whatever app you built, something in it is wanting to be deployed to O365.  This tells you that Microsoft is driving you to it by leaving out real OAuth endpoints in SP2013 in Beta.  You can find several differnt ways to get an access token in the beta but none of them really support the notion of a clientid and secret when working with on-premise.  Just FYI, one way (that is as close to OAuth as you can get) is particuarlly bad as it doesn't have any auth on it and I can get auth tokens all day long!!!

All that being said,  there are hints of the ablity to do this in RTM.  You can find several layouts pages (AppRegNew.aspx) dedicated to creating applications that live on-premise and use real OAuth calls (clientid and secret).  However, sad to say, nothing really works at the moment in the beta (believe me…I have tried). The fact that the code is even exposed about the ACS Service Application is because there is a generic interface that can be replaced in later code to make calls to other services, however, it looks like they just didn't get around to putting all the plumbing in yet.

So, don't fret about the above error, you can't do anything about it with on-premise apps. 
Chris

Posted on

Working with SharePoint 2013 Distributed Cache Service (DCS)

As part of the latest course, i wanted to show how to get in and see what was in the cache of SharePoint.  I also wanted to add my own items via web parts.  Since the DCS is really AppFabric, and I have worked with it before, I didn't see it being a tough set of labs to put together.  However, I found that all the SPDistributedCache classes are marked as "internal".   This leave the regular .NET API to make calls into the service layers.   I found a great little set of code written by Stephane Eyskens (@stephaneeyskens) here:

http://www.silver-it.com/node/111

That is one of the better pieces of sleuthing I have seen in a while!

Chris

Posted on

OAuth 2.0 – How long will it survive?

Yeah, lots of people are using OAuth.  Its evolution from WRAP->OAuth 1.0 has in my opinion been mostly good.  However, there are always the details of how something is built that makes you realize, not everything is what it seems to be:

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

After reading the article…go to the last part…I tweeted that all not too long ago.  I did the same for REST in SharePoint 2010.

You have to wonder.  Who is the "Enterprise" in this case?  Hint…My guess is the name starts with an "M" and ends in "T"

Chris

Posted on

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

Posted on

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

Posted on

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

Posted on

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.&nbs
p; 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