Reza Alirezaei’s Blog

As the saying goes, the devil is in the details! This meant to be a note to self, but I thought it might be helpful for some of you too. Here we go:

If John has “Read” permission level to a document named sales.docx, John is able to search and find this document and view it either in Office Web App on the server (in the browser), or in Office client on his computer.

If John has “View Only” permission level to sales.docx, John *can* browse to the document library and see the document, however John cannot open the document in Office Word client on his computer.  Lucky John, if Office Web App is installed, John is able to see the document online. Ok, I get it! John has “View Only” permission level and this level doesn’t have “Open Items” permission (See the product documentation here). So far so good…

Interesting part is here –> If John has “View Only” permission level to sales.docx, he is not able to find it using search.  Furthermore, if he types the URL of the document in the browser address bar (http://SharepointSite/doclib/sales.docx), he receives an Access Denied error. Now, I don’t get it! John has “View Only” permission level. He should be able to find the document via search, and see it using Office Web app just like how he’s able to do so when he browses to the document library and clicks on it!

This leads to two different security access behaviors:

1. If a user has “Read” permission level to a document, they can always find the document using search or browser and open it in the browser or their Office client app.
2. If a user has “View”Only” permission level to a document, they can only find and open the document in the browser. In that case, Search doesn’t show the document!

Conclusion: Looks like “Open Items” permission plays an important role in search security trimming on the core search result. This makes people with “View Only” permission level ( With No “Open Items” Permission) not to be able to search for the documents they are already authorized to view. Obviously, you can go ahead and change the OOTB View Only permission level , but then again, that’s not “View Only” permission level anymore!

Make sure you are aware of this difference when planning your site permissions.

Not sure if you noticed this, but in SharePoint 2013 when you setup a sync connection you can exclude disabled users by just clicking on a checkbox.

 

 

 

 

 

 

 

Given that, you no longer need to setup a filter like what you did in SharePoint 2010 ( see my blog post here):

 

 

If you are setting up Windows Azure Workflow and Service Bus in your SharePoint 2013 farm as per MSDN paper here,  it’s important to understand the role of workflow and service bus service account (RunAs account) to create the Windows Azure Workflow farm.

First of all, this account needs to have necessary rights to the SQL Server instance that hosts your SharePoint databases.

Second, you use this account every time you need to join a node to the workflow farm. Note Windows Azure Workflow farm and your typical SharePoint farm are not the same. They can co-exit on the same machine (for dev purposes) but in reality, they are on different machines talking to each other remotely over HTTP or HTTPs.

The workflow farm  will act as a workflow execution engine which lives outside of SharePoint. New architecture is all about the performance and scalability!

Windows Azure Service Bus and App Fabric are responsible for handling the widespread communication between the two farms while facilitating the messaging, tracking, persistence,etc.

Third, before you run the workflow config wizard on any nodes, you need to logon to that machine using the service account and then run the wizard. The workflow service account is not (and shouldn’t be) same as the farm account you used to install SharePoint. This is the service account that several processes of Windows Azure Workflow host and Windows Azure Service Bus will be executing under:

 

If you don’t run the wizard while physically logged into the machine, during the last step of the wizard “Add Host to Workflow Farm”, you will get a timeout error:

Add-WFHost : Could not successfully create management Service Bus entity ‘WF_Management/WFTOPIC’ with multiple retries within timespan of 00:02:07.9588733

Note: The timespan indicated in the error message might be different on your machine.

If you are getting this error, you need to clean up the failed installation by running the config wizard again and click on the “Leave Farm”, as shown in the following picture:

 

Next, you need to manually delete the associated databases (6 databases):

Once you’ve got this nasty bug ironed out , the summary page of the workflow configuration wizard should look like the following picture which is a good sign that you have successfully configured the workflow farm:

 

Obviously, you still need to pair your SharePoint farm with the workflow farm you just created. Now you need to log back into your machine using the farm account and run Register-SPWorkflowService cmdlet as per the MSDN article. On the SharePoint side, there are two ways to verify the pair up operation has gone successful:

1) When You browse to Central Admin > Manage Service Applications > App Fabric Application Proxy , you should see something like the picture below:

2) Now, you should be able to build declarative SharePoint 2013 Workflows from within SharePoint Designer 2013 and publish them to your SharePoint 2013 farm:

2-1) Open SharePoint Designer and browse to your SharePoint site.

2-2) Create a site workflow and verify that SharePoint 2013 Workflow exits. Go ahead and select it!

2-3) Add one stage, one action (Log to workflow history) and a “Go to end of Workflow” as the transition to stage condition.

2-4) Publish your workflow.

2-5) Browse to your site > View all Site Content > Site Workflows, and kick off the site workflow you just published.

 

2-6) Go to the workflow status page and verifying that the entry in the log history has been created.

 

This is a huge architectural shift in the way you implement your business processes in SharePoint and will definitely help improving the performance of your SharePoint farms.

Enjoy Windows Azure as the new workflow execution host for your SharePoint workflows!

Resources:

http://msdn.microsoft.com/en-us/library/windowsazure/jj193489(v=azure.10).aspx

http://msdn.microsoft.com/en-us/library/jj163276(v=office.15).aspx

Update: As of Oct 24, Windows Azure Workflow and Service Bus is now named “Workflow Manager” and it’s publicly available in Web Platform Installer (WebPI), Web Platform Installer Command Line (WebPICMD) and directly from download center here.

I am excited to announce that I have been working with Wiley Publishing as the lead author of a new book named “Professional SharePoint 2013 Development“. We put together a great team of well-known authors to deliver the best-in-class content for customers who are planning to build and implement enterprise scale solutions using SharePoint 2013 products and technologies.

The book starts with a great chapter on architectural changes in SharePoint 2013, then it will cover the new and improved areas. For the rest of the book you will see hands on, real life chapters focusing on major SharePoint 2013 features and workloads like ECM, BCS, Search, BI, Cloud and Social.

We have started working on this book for a few months. Just like our SharePoint 2010 version, we are working hard to be the FIRST book that comes to the market!

The book is now available for preorder on Amazon:

http://www.amazon.com/Professional-SharePoint-2013-Development-Alirezaei/dp/1118495829