Sterling International Consulting Group

Document Problems Using SharePoint With UAG

Email | Print

In a recent installation, we came across a few interesting problems when using UAG with SharePoint. Initiallly when testing, all appeared fine in the process – UAG correctly navigated to SharePoint, SharePoint Alternate Access Mappings appeared correct and all seemed right with the operation.We found however, when put into a staging environment (and production at the same time, though we’d advised against that), suddenly we began to experience all kinds of problems with opening documents. Some of the symptoms included:

1) Word/Excel documents would prompt three times then return access denied
2) When set to open in the Client automatically, it would prompt once then open a UAG error message in Word
3) Right clicking on a document and selecting “Edit in…” seemed to work OK
4) PowerPoint slide libraries simply would not open
5) Unable to publish new slides

Oddly enough, all of these issues ‘mysteriously’ appeared – in the development environment, none of the problems were occuring. As a test, we created another site and routed UAG to it – most problems went away but the PowerPoint slides were still not working.

After many, many hours working the issue we discovered that under UAG there are a few issues that were not accomodated for.

In the case of the documents prompting, final analysis determined that in fact, one of the developers had enabled Debug in the web.config file of the SharePoint site (we assume accidentally deploying to production from Visual Studio though it appears it was in fact an attempt to debug in production). The problem as it turns out is within UAG – when in Debug, SharePoint reverts to using the ECMAScript mode – that is, all JavaScript files revert to their ‘unpacked’ format for debugging. In specific, a file SharePoint uses called init.js uses init.debug.js when in debug mode – UAG cannot understand that, causing the disconnect.

Deployment tip: If you are using UAG it is likely that a staging/development environment will have Debug enabled; it will not be possible to test user access when in this state.

NOTE: At the time of this writing, we created and issued a DCR to the product team to correct – using debug mode should enable the entire environment to be debugged without setting aside major functions.

In the case of PowerPoint, the ‘debug’ mode was a factor in the inablity to publish. However, the rendering problem turned out to be unrelated – this issue turns out to be at the server. It appears that without the “Desktop Experience” Feature installed on the server, PowerPoint Slides are not rendered correctly (and its usually not a feature added in a Production environment). To correct this, on each front ender server, open up the Server Manager, select Features, click on Add a Feature, locate Desktop Experience in the list, click the checkbox to select it and click OK to add it.

By Sterling International Consulting Group – North Carolina SharePoint Partner

Related Posts

Ask This Expert a Question or Leave a Comment