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

Moving from Azure WordPress Website to Azure VM

After moving my SharePoint blog site to an Azure WordPress website, I realized that the MySQL database was also in the cloud with ClearDB and was limited to 20MB which doesn’t really give me much space to grow. I thought a good idea would be to just create my Azure VM with a WordPress install and MySQL instance on it and then migrate the site again.

Since my site was now in WordPress, I figured the migration would be easier.  I was able to find a nifty plug-in called “UpdraftPlus Backup/Restore“.  This enables you to just install the plug-in on both the source and target WordPress installs and then just restore everything (Including plug-ins and themes). With a plan in mind I decided to go for broke.

So the journey began and I did the following:

  1. Created an Azure VM (using the Server 2012 R2 template).
    • Added Application Server Role with IIS
    • Installed Web Platform Installer then added MySQL and WordPress
    • Put www.xenox.net and xenox.net entries to 127.0.0.1 in the hosts file
    • Launched WordPress with the default install using my same URL as a host header
    • Installed UpdraftPlus Backup/Restore plug-in
  2. Backed up my original WordPress site running on Azure
    • Installed UpdraftPlus Backup/Restore plug-in
    • Ran a backup and downloaded all files (Database, Plugins, Themes, Uploads, Others)
    • Copied .zip and .gz backup files to the new Azure VM
  3. Restored back-up files on new Azure VM instance
    • Uploaded backup files within the UpdraftPlus plug-in by dragging and dropping them in.
    • Performed a ‘Restore’
    • Logged back-in with user credentials from the original WordPress site.
  4. Verified site functions locally
  5. Updated DNS with my ISP to point to the public IP address for my Azure VM

I realized that the cost of running the Azure Website was $.01/hr more than the cost of running the Azure VM (for a comparable size).  I know this new setup is going to be more of a maintenance overhead for me, but it will give me an excuse to keep up to date with everything and also be able to RDP into the server.