Automation–MVP Spotlight Series–SharePoint: DFS Share Creation Request Walkthrough (Part 1)

Okay Readers – we are back!

Here is the second of six posts in the MVP Spotlight Series for the Automation Track…

–MVP Spotlight Series–

SharePoint: DFS Share Creation Request Walkthrough (Part 1)

by Mike Roberts (a Ryan Andorfer Co-Worker)

Building Self Service Requests Using SharePoint

This blog post doesn't focus explicitly on automation but on a related topic that is crucial for connecting automated requests to the end-users who need them. In this post I will detail how we built a self-service request portal to allow end-users to access the processes we have automated using Service Management Automation.

Here (color portion) is a look at where this post fits in to the overall example Solution Architecture:

Before we dig in to all the technical details of our implementation, it's worthwhile to consider our goals and motivations for this portal. The key objective of this project is to empower our users to solve their own problems without direct intervention of IT staff. The naïve approach to this would be to grant users higher permissions and access rights, so that they may directly provision resources like Active Directory groups, DFS file shares, and servers. Clearly, this may enable some short-term productivity, but would lead to all manner of technical and governance problem. The key is finding the middle ground, and the self-service portal should allow us to delegate our authority to users but to do so with appropriate controls so that requests don't violate policy or destabilize systems.

Requirements

With this philosophy in mind, we generated the following list of requirements for an implementation technology:

• Input Forms - This one is pretty basic. The self-service portal must provide its users with a means to submit requests to be processed by the back-end automation engine. Since this solution is intended to be used by IT Pros, web development experience shouldn't be necessary to create forms. Additionally, there should be a variety of input controls and a means to validate user input.
• Security - The self-service portal must provide the means to restrict which requests a user can access, based on Active Directory group membership. There should be appropriate controls in place to ensure validation logic and business processes around each request cannot be circumvented.
• Accessibility via APIs - There must be a means to "connect" the self-service portal to SMA, our automation engine. Since SMA Runbooks are authored using PowerShell Workflow, it is important to consider how easily the portal's APIs can be accessed using PowerShell cmdlets.
• Human Workflow processes - The portal should provide a means to implement the business processes and governance that apply to each request process. Typically, this means the ability to route a request for approval before it is processed by the SMA Runbooks.
• Good User Experience - Finally, it's crucial to keep the end-user's experience in mind. If the system is too confusing or frustrating to use, it won't be adopted and users won't get the value of automated self-service requests.

We evaluated a number of different technologies based on the criteria above and landed on SharePoint as an implementation technology for our self-service portal. Our enterprise already has a large SharePoint deployment, so business users have familiarity and comfort with the technology. SharePoint enables us to design attractive web forms by configuration, has a wealth of APIs to access data from PowerShell and robust workflow automation capabilities.

Request Form Creation

For the purposes of this post, I'm going to use the example of requesting a new DFS Share. This request provides a good example of how SharePoint meets our requirements: it has a variety of inputs which require validation and an approval process to ensure the request is appropriate. Here is the information that must be collected to create a new DFS Share:

The first step is to create a new SharePoint list in our site. Click on the gear in the upper right-hand corner of the page to open the Site Settings menu and choose Add an app.

On the next screen select the Custom List app.

Choose a name for your new request list and click Create.

Now SharePoint will drop you in the Site Contents page and you should see the list you just created highlighted with a green tag that says "New". Click on this to open the list.

Our SharePoint list is pretty basic at this point. It only has a single default field named "Title". We want to add fields to match the list of required inputs for DFS share creation that we reviewed earlier. To do this, click on the List tab on the ribbon and click on the List Settings button.

This screen allows you to manage your SharePoint list. If you scroll down a bit you can see the current listing of columns in the list, which are all defaults created on a new SharePoint list. The title column can't be deleted, so we're going to re-use it. Click on Title to edit the column and change the name to "Share Name". You can also add descriptions that will be displayed alongside the input controls to give users more guidance on what to enter.

Next we need to create columns for our other input fields. Click the Create Column button to go to the creation dialog. Here you enter a title for the new field, choose its data type and configure it.

Once we configure these fields on the SharePoint list we can open up the new item form to see what we have.

It's a promising start, but there is clearly some more work that needs to be done before we can present this to our users.

We need to add validation to the Share Name field, configure the Initial Members field to display only when the Secure Share box is checked, andremove the Status field from the form so that users cannot create requests in a status other than "New".

Some basic validation can be accomplished just by configuring fields in a SharePoint list. However, to meet our UI requirements we are going to have to use an additional tool called InfoPath. InfoPath is a thick-client application that it part of the Microsoft Office suite. It allows users to customize SharePoint forms and add complex validation logic without requiring web development skills.

A this point it is worth noting that Microsoft does not plan to continue support for InfoPath in future versions of SharePoint. However, Microsoft will continue to support InfoPath and SharePoint 2013 for years to come, per the software support lifecycle.

To launch InfoPath, navigate to the SharePoint list, click on the List tab in the ribbon and click Customize Form.

This will launch the InfoPath client application with a copy of your SharePoint list's input form ready to be edited.

Our first UI modification will be to remove the Status field. Simply highlight that row in the table that contains the Status input and hit delete. Now the user has no option to change the value to anything other than the default value of New. You can do the same for the Attachments row that appears below share name since we won't be using attachments on this list.

Next, we want to restrict the text that can be entered in the Share Name field to alphanumeric characters and the dash sign (-). Click on the Share Name field so it has focus.

Then click Manage Rules in the ribbon.

This opens up the Rules pane on the right side of the screen which will allow us to define validation rules for the input control. Select Validation from the New dropdown.

Now enter a name for your validation rule and a ScreenTip that will be presented to users when this rule is violated. To define the rule click the text None under "Condition:"

In the Condition dialog that pops up, change the middle drop down to select matches pattern. This will allow us to define a regular expression to match our expected input. Select Custom Pattern and enter the following regular expression:

[a-zA-z][a-zA-Z0-9\-]+

The very last step is to ensure that the user is only prompted to select Share Members when the Secure Share box is checked. To do this, place the cursor below the Share Members field and insert a Section from the Input menu on the ribbon.

The section is just a container control that we are going to use to conditionally show/hide the whole table row. Next, highlight the Share Members row in the table and Cut it by pressing Ctrl-X.

Then paste the table row inside the Section control. Now we are going to create a Rule to conditionally hide the whole section control when Secure Share is not checked, so make sure you have the section control highlighted.

Type a descriptive name for your rule and check the Hide this control checkbox. Click None to define the rule that says when the control should be hidden.

Use the condition dialog to hide the Section only when Secure Share is unchecked, or equal to the Boolean value FALSE. With all of these modifications complete, we have our finished input form that will allow our users to request DFS shares.

Securing the Request Form

One of SharePoint's strengths is that it gives users a wealth of ways to interact with the data it stores in lists and libraries. Users have the option to work with their data in web forms, datasheet view, or even using a variety of web service calls. However, this can make life more complicated when you are trying to restrict the actions a user can perform. For our solution to be secure, we need to ensure that the following requirements are met:

· Users can see only their own requests. The requests submitted by other users might contain sensitive information that should not be made public.

· Users cannot modify a request outside of the InfoPath form and bypass validation.

· Users cannot access requests that they are not authorized to use.

We will make the following configuration changes to ensure these restrictions are enforced. However, following the principle of "defense in depth" it is recommended to validate all inputs inside automation scripts as well. This gives us two layers of protection should a malicious user try to circumvent the controls we've put in place.

The first requirement we are going to tackle is preventing users from accessing each other's requests. This can be accomplished with a quick change to the list settings. We navigate to the list settings page as we did before to add columns to the list. The options we need to configure are available under Advanced Settings on the left in the "General Settings" column. To restrict users to their own list items we will select the options as shown below to prevent them from seeing or editing other users' list items.

We added validation to our input fields in our InfoPath form to prevent users from submitting bad or potentially malicious data. However, this is where SharePoint's flexibility makes our life difficult. Users could sidestep our input validation by submitting list items directly through SharePoint's web services. We need a way to prohibit this. We should also disallow users from editing list items after they have been submitted because they could change after approval workflows have run.

To accomplish this we are going to create a new permission level. In SharePoint a permission level defines a set of rights that can be granted to a user or group on a securable object. We want to define a set of rights that allow users to submit new items, but not edit or delete items, nor use SharePoint's web services to manipulate the data in the list. We start by navigating to Site Settings from the site settings menu (the gear in the upper right corner of the page).

From Site Setting we navigate to the Site Permissions page.

Then click the Permission Levels button on the ribbon of the Site Permissions page.

To create our new permission level, we can start with an existing level, copy it, and make the needed modifications. The closest match for our scenario is Read, so click that entry to open the permission level.

Then scroll down to the bottom of the screen and click Copy Permission Level.

Give the new permission level a title and description.

Then ensure that the Add Items box is checked to allow users to submit new items.

Also, uncheck the check boxes next to Use Remote Interfaces and Use Client Integration Features to exclude web service access from this permission level.

Click Create to submit the form and finish defining our new permission level. Now that we have defined the set of rights we want our users to have, we need to grant them this level of access to our request list. To do so, navigate back to the list settings page and click Permissions for this list.

By default all lists in SharePoint inherit permissions from the site level. Since we want to assign a unique permission set to our list we need to break inheritance by clicking the Stop Inheriting Permissions button on the ribbon.

Now we can set permissions for site visitors on our list by checking the box next to the group Self Service Portal Visitors and clicking the Edit User Permissions button on the ribbon.

Check the Submit Only box to grant visitors access to submit new items and click Ok.

This completes the configuration of our list so that users may securely submit requests.

Hopefully this post has demonstrated how SharePoint can be configured to allow users to submit self-service requests for IT services. In the upcoming blog posts in this series we will see how to configure a request catalog to organize and display self-service requests and how to use SharePoint workflow to automate approval processes. Then we will demonstrate how requests are serviced automatically by Service Management Automation to enable true self-service IT.

And now a few notes from me (Charles)…

Be sure to check out Ryan’s session from TechEd North America 2014!

And finally - As always, for more information, tips/tricks, and example solutions for Automation within System Center, Windows Azure Pack, Windows Azure, etc., be sure to check out the other blog posts from Building Clouds in the Automation Track (and https://aka.ms/IntroToSMA), the great work over at the System Center Orchestrator Engineering Blog, and of course, Ryan’s Blog over at https://opalis.wordpress.com!

enJOY!