Friday, July 19, 2013

SharePoint 2013 - Proxies, CRL Checks and the App Store...

OK, so I've been messing with SP2013 for a little while now.  Built a VM when when it first came out, ignored all the errors and warnings and built a little RSS based workflow.

More recently I've been taking it more seriously and have been working with AutoSPInstaller to get a clean, consistent, working Dev install (single server + separate SQL2012SP1).

It's been a bit of a mission, not because of AutoSPInstaller, but primarily because our environment sits behind an authenticating proxy.  Which means I get a lot of CRL Check failures.  "No worries" you say, "AutoSPInstaller has a disable CRL check setting!" which is true, unfortunatly it doesn't cover all the CRL checks (which might not even be possible).

I found that if I disabled the CRL checks (using AutoSPInstaller) then my Distributed Cache service would be highly unstable and basically repeatedly crash as it started up.

So in comes plan B, set up a non-authenticating proxy, courtisy of Fiddler. We have a handful of VMs that are able to connect to a non-authenticating proxy so that they can connect to the internet (yes, they all happen to be SP2010 machines...) so I just run Fiddler on one of those and set it to be my proxy on the SP2013 machine.

OK, so next is to figure out which accounts need proxy access... what fun, it seems that the SPFarm, SPServices and SPContent accounts all do CRL checks...  So I figure I'll write a little PowerShell to set the proxy for each service account... Long story short (account has to be running, IE has to have created it's reg settings...) it didn't work.  Not entirely sure why, so I just abandoned the script and now I manually launch IE as each user, set the proxy and close IE.

Bingo, all my CRL check errors are gone!

Until I try to install Apps from

Turns out, the Apps part of SP2013 uses the local IUSR account to do the CRL check (go figure). So how am I going to set the default proxy for that account?

Turns out:
netsh winhttp set proxy ";*"
is enough.

Note: is the domain I'm using to host my SP apps, you should set yours to match whatever you've configured up in Central Admin for your App URL.

Production will be similar, though I should be able to set the proxy to be the proper non-authenticating proxy, rather than my Fiddler proxy.

Isn't it time MS realised that many organisations run authenticating proxies and that products need to provide better support for this scenario? (Ever tried running the Twitter PowerView demo?)

Oh well, I'm a happy camper now, I have a working SP2013 environment, with Apps! (Still working on some other errors though....)

No comments: