SharePoint Permission Pain

<rant>

I just need to go off for a minute.  I just got off the phone with a “SharePoint guy” for the leadership for some potential work that I am not going to do.  These individuals do not know or understand SharePoint from the fundamental understanding of how they’d like to use it for the enterprise to the understanding of where to click to do simple things.  They wanted control so much, they would not give me full control to their site.  They told me they’d give me design but then take it back each day when I had no more need for it.  The “SharePoint guy” doesn’t know SharePoint or else they’d have him build these libraries.  We aren’t even talking hard stuff.

The leadership—these mid-level managers—would have full control.  These are the same people who don’t know how to use SharePoint and could really use a class.  They have full control and the guy (me) who had designed the permission architecture they agreed to kind of sort of use a few months ago—it took this long for them to agree to implement what they believed was a good design—gets design.  I will not have the ability to alter the master so that I could put a disclaimer banner of sorts on each page of the site that regulations mandate they do.  The people running their farm haven’t bothered to implement these banners in the last six or so years they had the environment up and running.

</rant>

It really blows my mind.  I feel like Beatrice from the Essurance ads.  “That isn’t how any of this works!”

So how does this happen?  I won’t say it is Microsoft’s fault.  That would be an easy cop out that a lot of folks use far too easily.  Understanding how to use an expensive platform like SharePoint should fall on the shoulders of the people who decided to purchase it, whether they learn it themselves or trust in the people they decide to hire to manage it.  The problem is that few people bothered to question whether or not Team Site Owners, Team Site Members, and Team Site Visitors are the appropriate permission groups a site should have.

Leadership, those with rank and privilege in the organization, own their content.  No one should ever question that, but when someone creates a new site and sees an owners group, they automatically assume that the data owners are the Team Site Owners.  Now, these individuals who are too busy to take a SharePoint 101 class and probably don’t even have the time to open all of the email in their inboxes are the ones who will get the access requests because they didn’t bother to adequately plan for all of the people who will need to access the site.  They will give all of the underlings, including the younger more technically savvy members of the team, only contribute permissions, often by individually granting them permission rather than putting them in the Team Site Members group.  Often, I’ll see that they will add everyone outside of the team to the Team Site Members group because Microsoft defaulted the description of the group to say something like, “Use this group to grant people contribute permissions to the SharePoint site: XYX.”  Eeekk!!!  “Hey, let’s go create another 100 sub sites with new permission groups for each of them and manage them this way so that Bob Smith needs to be added to 100 XYZ Members groups!”  Some of these people think this is not just acceptable but encouraged because the site creates these groups with that description automatically.

The data owners—leadership of the organization—should get their own group.  That group should be given contribute or read permissions to all of the content they might want, which may or may not be everything on the site.  They might not want to see 50 libraries on the site.  Maybe they only want to see the links to lists and libraries they give a damn about because they only care about the 30,000-foot view of the data and don’t care about how you make the sausage.  That is assuming they are good leaders/executives.

Think about the user experience for yourself as someone who has SCA rights or full control to a site.  You get to see every single list and library as links in the quick launch or global navigation or custom menu thing you’ve built.  That can be a little overwhelming for most of the users.  It is like sitting down in front of the menu at the Cheesecake Factory.  They make a wonderful Cuban sandwich if you haven’t tried  it yet, but do you know how much other stuff I ate before I found the sandwich I hold so dear?  The more things you give them to click on, the longer they will take to make the decision as to what they’d like to click on.  We’ve already discussed that the leadership doesn’t have that much free time.  Why would you agree to make their lives harder because they want to micromanage what you are building for the workers in the team to enable them to be more efficient in what they do?  Push back.  They didn’t get where they are because they are stupid, but they are ignorant or ill-informed because of a lack of training and bad SharePoint people.  You do them a disservice by not educating them when they demand full control.

That is enough for now.  I’m happy to get it off of my chest.

Lessons: Developing a SharePoint app for a high trust environment

I just went through the harrowing experience of developing a SharePoint app for a high trust environment. Some of it was due to office politics, while most was due to plain miscommunication and incompetence.

There are some important lessons to be garnered which I think apply to any instance in which you are contemplating developing an app for your environment.

  1. High trust apps cannot be “ported” to cloud solutions, such as SharePoint Online or Office 365. If you code your app correctly, you can reuse the code and the overall framework of your app. For instance, I coded my app using the Client Side Object Model (CSOM), which is one of the recommended languages that Microsoft wants you to use when building an app; therefore I can reuse my code should my client want to move to the cloud in the future.
  2. If you are going to be developing a high trust application, you need to make absolutely certain that your infrastructure is appropriately configured. This is way too much of a topic to cover as it is expansive, and I don’t say that lightly. It doesn’t help that Microsoft’s own documentation is lacking and in some cases just wrong (I’m looking at you, MSDN Powershell code). If your environment is not configured properly, you will be fighting an uphill battle with an almost infinite number of possible moving factors which might cause your app to fail.
  3. Consider the return on investment (ROI). If you can accomplish the same end goal building a traditional, farm based solution, I would advise you go with the latter and not the former just because it’s newer and shinier. Chances are if you are building an app in a high trust environment, like I was with my client, there is no chance you are going to the cloud anytime in the near future, irrespective of what the Microsoft talking heads are telling you. Plan and build accordingly. Be smart about the choices you make when contemplating the SharePoint app model versus a traditional solution.
  4. LISTEN TO YOUR INFRASTRUCTURE PEOPLE. Just because other developers on the ground happen to be Microsoft, this doesn’t mean they are the best equipped to be giving you input on the solution you are building. Your app will only be as successful as the actual configuration of the environment you are deploying on. Make sure you get all the appropriate certificate serial numbers, issuer IDs, and token information necessary for your app from the infrastructure folks.

With SharePoint 2013, there are some quirks which just cannot be overcome with a standard, traditional farm solution, irrespective of the code you write. In this case, you will have no choice but to write your app using the app model. I had this misfortune particularly with the site collection provisioning process, which at a certain step could not be overridden no matter what using a traditional farm solution, but that is a topic for another time.

What is high trust? High trust is basically the same concept as with a traditional farm solution, in which your app will have “superpowers” to the farm, and therefore can have the same ramifications as a traditional solution if something were to go wrong. Where it deviates is the fact that you can build your app so that it is hosted completely outside of SharePoint, therefore isolating and preventing it from screwing with your SharePoint instance. Therefore, your app can go “down”, and will not take SharePoint with it.

This topic can go on and on, but that is it for now. I’ll have much more to share in the near future.

SharePoint Testing

I just realized I’d left this unpublished from a few weeks ago. This should have been published before my trip to SharePoint Saturday Atlanta.
—-BREAK—-
So I’m working with a new client again, and I’m seeing what I’ve often seen with other previous clients: test sites and test lists and even testtesttest2 lists. This drives me nuts for a few reasons:

  • They are usually old. If you don’t know your job as a SharePoint person and need to create a test list for you to figure things out, admit you don’t know how SharePoint works.
  • They lack any kind of context. It might have just the title column, no records, and modified last 5 months ago. How do I know if it holds any value to anyone whatsoever?
  • Whoever made them didn’t change the permissions or correct the navigation for it. This is what drives me nuts the most. Not only do you obviously not know the platform, you are advertising it to everyone who can see the site that you don’t know what you are doing and are cluttering up their UI.

If SharePoint were your house, we’d already have had an intervention for your hoarding.

Just stop it already.

In another client’s O365 environment, they were looking to create another web application (paying a lot more money by the way) to have a testing area, but they weren’t doing some kind of crazy code affecting O365. It wasn’t necessary at all. I’m glad I stopped them.

So here is my freebie to everyone out there.

O365/SharePoint Online Users

If you are an O365 customer, you might want one site collection as a test environment.

Why?

Because you do need a place to train other people and a place to make new masterpages without deploying the new look and feel right into production. I’ve seen too often someone create a new masterpage and roll it out without being approved properly. Bad idea. Create the new site collection and then a NEW copy of the masterpage. NEVER edit the defaults. Just don’t. Work with it there and fill the site with a bunch of lorem ipsum junk text. You’ll get a better feeling for how things will look. Also, don’t forget to add a few dozen links to your quick launch and global navigation to see how well they look under the new master.

You do not need to put new lists in this environment to test them and then build the exact same thing in your production sites. That is just silly. That is beyond silly. This is not traditional application development with rounds and rounds of software development design meetings and half a dozen folks creating their own pieces of code that others will piece together to make this one beautiful application in six months. SharePoint is a middle platform to create applications in minutes. If you don’t like it, delete it. If you create it properly, use the same content type over and over to make the application for multiple groups of users.  It could also be that place where you and only you have your test lists because you don’t know how to make a feature work properly, but that still wouldn’t be the best place for the test list.

SharePoint 2013 On-Premises Users

You have the world as your oyster with your own environment, but you still load it up with test sites and lists.  Shame on you.  Other options are available and here is what you need.

Scenario 1:  We will write custom C# applications that will need binaries injected in the hive.

Solution:  Build another farm.  Scale it to have the same number of web front ends (WFEs) running the exact same version as production.  You will only need one SQL box on the back end.  All we are trying to do is replicate the environment as much as possible with far fewer resources like memory and storage.  You will need to change files on the WFEs in this scenario.  While highly customizable, this is really only advantageous to very few customers out there doing some really amazing things.

Scenario 2:  We will write some custom JS, CSS, and HTML and use the client-side object model (CSOM) to make things pretty and more functional.

Solution 2:  Still build out a second farm.  BUT why?  If you are an IT systems administrator who has been in this business for more than a year, you will know and will probably have experience of getting a patch that has broken a server or two, especially after you have hardened the servers (STIG’d in my market) to make them more secure.  How do you know which patches from Microsoft or any of the other third party applications that you have running on all of your boxes will not screw up your environment?  You test.  You will only need one WFE.  The SQL instance will be a new instance on a cluster that you are using for ALL of the other SQL things going on in your environment.  Again, we are trying to replicate your environment with as few resources as possible.

But what about SharePoint testing?—Aside from testing a cumulative update before adding it to all of the WFEs in production, you don’t need to use this test environment for anything else.  If you aren’t running any monitoring software that you need to patch on your production WFEs, you might not even need this.  Microsoft has an OK record of not destroying SharePoint farms with patches, but it is by no means spotless.  I do recall a few years ago a 2010 update that screwed up a lot of folks.  Those patches are the only things you are testing.  You aren’t testing lists, web parts, sites, or anything else.  Don’t even give anyone else the URL if you are the systems admin or farm admin for SharePoint in your IT department.

So where do you test things?

In production.  Let me explain it as simply as I can.  When you write up a document in word and it is in draft form, do you keep it on a different computer?  When it is ready to print, do you copy it out of the draft version and paste it into a clean document?  Of course you don’t.

Build the entire application right where you need it.  The key is to change the permissions on the list/library/site/etc. to the pieces of it so only those involved in building it can see it.  When it is ready for go-live, change the permissions.  That is it.  You can even update your navigation, unless you are creating a lot of hard links, because security trimming in SharePoint won’t show those links to people until they have the permission to see them.  If, however, you are using a lot of hard links in the navigation, set the audience on those links to just those involved in building.  When the application is ready for go-live, take the audiencing off.

If you are a client, looking for good SharePoint folks and you see a bunch of test crap in your environment after you hire them, recompete that contract ASAP.