From SharePoint to Dynamics

It has been a long journey from my first foray into SharePoint back in 2007 as a .NET developer at the University of Washington to a Dynamics 365 consultant at Microsoft.

Although I joined Microsoft back in 2015 as a SharePoint consultant, I quickly found that my clients were pushing their use of SharePoint well beyond the limits of relational lists and libraries. Once there were more than two lookup lists with other related data, the kinds of insights and reporting that would need to be customized and maintained over time made SharePoint look less appealing as a platform for enterprise solutions. Of course there is always a place for document collaboration scenarios, but the kinds of relational database applications that were being built clearly had Dynamics written all over it.

Fast forward 3 years and I have a similar thirst for building that I did back in the SharePoint hey-days when quick business value could be realized in short time frames. The ability to also integrate a public website with CRM data as part of Dynamics 365 Portals makes the platform even more appealing.

Getting SharePoint Hosted Apps with Workflows to work with self-signed wildcard certificates

SharePoint hosted apps have been both a blessing and a curse for me.  The blessings have more to do with the concept of having a self-contained application that runs using client-side code only and can be centrally managed via an app catalog. The curse is the initial configuration of the environment to fully support SharePoint hosted (and provider-hosted) apps with SSL. I needed to configure wildcard certificates for SharePoint Hosted Apps in my development environment.

Mismatched Address for Wildcard Certificate

Now, everything may seem to be working fine with SPHosted apps if you follow the Microsoft guidance for setting up an on-premises environment for SharePoint apps, however my environment is a complete install so I went with Microsoft guidance on how to create an environment for apps for SharePoint. I also wanted to use SSL and the Workflow Manager and I wasn’t about to put down some cash for a 3rd party certificate. Although the use of a self-signed certificate seemed to work just fine for my main SharePoint url (servername.mydomain.net), I did come across some issues with a ‘Mismatched Address’ when I setup a local DNS with a forward lookup zone for routing my SharePoint apps app domain url (guid.appdomain.net) because my self signed wildcard certificate was self-issued by my own server.

mismatchedaddress

I can deal with just ignoring the error in the browser and be on my way with a functional SharePoint hosted app, but I ran into issues with Workflow.

SharePoint 2013 Workflows don’t work

Don’t get me wrong, I tested the SharePoint 2013 functionality using SharePoint Designer 2013 and was able to publish a workflow and get it to work.  The real issue came from the following simple scenario:

  1. Create a SharePoint Hosted app with a list instance
  2. Add a workflow and associate it to the list instance (Manual, item added or updated).  My simple workflow just writes to the log and updates the title with the current date/time.
  3. Install the app and add a list item

simpleworkflowassociation

simpleworkflowvs

What ended up happening is the workflow would start, but nothing would happen.  I knew that workflow was working, and I knew that my SharePoint hosted app was working, but for some reason the workflow would not get past Started.  What could be the problem?

errorworkflowstarted

Debugging the workflow issue

Although opening up the workflow properties showed the workflow and let me see when it was last run, hovering over the little blue ‘i’ for more information came up empty.

errorworkflowstarteddetails

The ULS logs didn’t really give me any more useful information either: “Workflow instance someguid is in retry state but GetRetryMessage threw exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.”

So I was off to the Event Viewer to see what was amiss. I dug down into the Event View -> Applications and Service Logs -> Microsoft-Workflow section and then made sure to allow the viewing of ‘Show Analytic and Debug Logs’.

enableanalyticanddebuglogs

Then I had to enable the Debug Log to see what was going on.

enabledebuglog

I came across an interesting error “An exception was thrown from the HTTP request to ‘https://app-guid.domain.net/Site/AppName/_vti_bin/client.svc/web/lists/getbyid(guid’somehexnumber’)/Items(1)’: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.”

workflowexception

Boom! I disabled the debug logging and then realized from this error that my Workflow was trying to make a service call to the SharePoint hosted app but was failing to communicate because of an SSL issue. I’m thinking the mismatched address was causing this to occur and I couldn’t just click ‘Continue’ because it was happening asynchronously form the server.

Creating a self-signed wildcard certificate

I’m not an SSL expert by any means, but I happened to stumble upon an excellent post by Mike O’Brien about Creating a self-signed wildcard certificate.  I followed this blog post to create a new root Certificate Authority as the issuer of my wildcard cert for my SharePoint app domain using the following 2 commands in an elevated Visual Studio Command Prompt:

 Workflows within a SharePoint Hosted App are functional again

Now I could select my *.appdomain.net SSL certificate as my default within IIS site bindings for my Web Application.  I then could open up my browser to try my SharePoint Hosted app with workflow.  When I checked the status I saw that my workflow instance had completed successfully!

completedworkflow

Anonymous Access for SharePoint Public Website Office 365

For those of us who have been playing around with SharePoint Online (Office 365) since Wave 14, the ability to allow Anonymous users to interact with your public site was a great feature.

When Microsoft moved to Wave 15 and then changed up the Small Medium Business (and Enterprise tenants) to use a severely limited public website interface, the ability to grant anonymous access to users to see list data was taken away.  I had written in the past about granting permissions using a custom web part, but it seems like this didn’t work anymore in the P1 tenants (or any non-Enterprise tenants).

What I discovered recently is that the solution still works, but since it uses code within an Sandbox Solution, only Enterprise tenants can execute the solution because a configuration change is needed to increase the Server Resource Quota for your ‘public’ website.  The default is set to zero (0) which allows declarative XML for sandbox solutions, but doesn’t allow any code (either feature receiver or web part code) to execute.

AALPPublicWebQuota

I couldn’t find a way to increase this in a P1 tenant because there is no interface for resource quota, but once this is set to a non-zero number, you can access the solution gallery on your public site by appending /_catalogs/Solutions/Forms/AllItems.aspx to your public site URL (for example: https://xenoxdev-public.sharepoint.com/_catalogs/solutions/Forms/AllItems.aspx)

Once the sandbox solution is activated, just add the Anonymous Access List Permissionator web part to a page and follow the blog post referenced here.

AALPPublicWeb

I created a sample list and put it on a development site.  You can even grant ‘AddListItem’ permissions for anonymous users.  Check it out here:

http://xenoxdev-public.sharepoint.com/

AALPPublicWebAdd AALPPublicWebCustomers

Good luck and use it while you can because it looks like Microsoft is taking away the Public Website and it will only be good for two years.

The webpart can be downloaded here:

WSP: AnonymousAccessListPermissionator

ZIP: AALPSourceCode.zip