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.

Add a Link to Manual Workflow

I’m building out a little thing for the company’s recruiters for when we add a friend to the list. An email goes to the boss of all of the recruiters saying one dropped. I have a link to the resume and the item, but I also had all of the pertinent information in the email. So even though the boss would be able to click on the link, go to the list item and click on my custom button to assign a recruiter, I thought I could cut out a step. I just created a link to the workflow I use to assign the recruiter.

ManualWorkflowPostPic0

The URL for that looks like this:

https://xxxxxxxxxxxxxxx.sharepoint.com/wfsvc/6f981489c973485293741943682bda4a/WFInitForm.aspx?List={1519fb4a-ef7b-468f-ad4f-7b0b2fea8f6a}&ID=8&ItemGuid={83D33457-7C55-41F9-938D-69143006E3AC}&TemplateID={B7CB07B2-F62C-49D2-9848-11858888F65F}&WF4=1&Source=https%3A%2F%2Fxxxxxxxxxxxx%2Esharepoint%2Ecom%2FLists%2FReferAFriend%2FAllItems%2Easpx

I know that looks like a crazy URL to build, and it is.

First, you can strip off the source. That is so SharePoint knows were to drop you after you submit. It is coming from an email, so we only really need to build this:

https://xxxxxxxxxxxxxxx.sharepoint.com/wfsvc/6f981489c973485293741943682bda4a/WFInitForm.aspx?List={1519fb4a-ef7b-468f-ad4f-7b0b2fea8f6a}&ID=8&ItemGuid={83D33457-7C55-41F9-938D-69143006E3AC}&TemplateID={B7CB07B2-F62C-49D2-9848-11858888F65F}&WF4=1

It comes in a few parts. You know what list this is, so we have the front of the URL, the list GUID, the ID, the ItemGUID, and the template ID. Separating much of these are braces {} so that the URL is constructed correctly. I thought I could use this string:
ManualWorkflowPostPic1

Well, guess what. There is no way to add those braces to a string. Microsoft will send you back this error:

ManualWorkflowPostPic2

That is unless you put those into their own variables. So I made all of these variables for the GUID, ID, open bracket, and close bracket:

ManualWorkflowPostPic3

Then, I changed my string to this:

ManualWorkflowPostPic4

Now I am able to insert it into my email to the management.

ManualWorkflowPostPic5

The management doesn’t like going outside of Outlook for anything, so this is the best middle ground I could do until I build an Office Add-in. I might do that in three years.

A Screw Loose

I often complain about neck pain. I usually share this with people soon enough because people ask me why I hurt, so I’ll just save my breath a little and tell everyone. It still hurts, but it isn’t like it used to be. On January 17, 2011, Martin Luther King Jr. Day, a guy pulled out of a parking garage and attempted to make a left on a four-lane road, K Street in DC. There was a bus blocking his view of me coming down the road, so he hit my passenger side. I didn’t notice the pain at first. In fact, it was several weeks later when I was driving on the highway and sneezed. Half a minute later, I felt this electrical pain going down my left arm. Considering my family history, I thought I was having my first heart attack. I pulled over and started to cry. I thought it was over, my life was done, no one could save me now. After two minutes of some excruciating pain, everything was normal again. No pain. Laughing hysterically, I knew I dodged a bullet but needed to see my doctor.

Long story short, my neurosurgeon figured out it was because of the accident. He eventually gave me a cervical fusion of C5, C6, and C7 by going through the front of my neck and pushing my throat to the side. I was off work for six weeks. My daughter was just six months old at the time of my surgery, eight months after the accident. The doctor forbid me from picking her up for months. Some of the drugs made me feel just stupid. I’d stop in the middle of my sentences forgetting what was going on. I went back in periodically to get a check up. Each time I got new X-rays. A little more than a year after the surgery, I was starting to feel a lot more pain without any more activity. My X-ray showed something scarey. One of the bottom screws in C7 had come out a little bit. I literally have a screw loose.

The bottom screw there pokes out 3.5mm.
The bottom screw there pokes out 3.5mm.

The doc decideded I needed another surgery to put to metal rods in my neck from the back instead of the front. Because the penticles (pieces of the vertabra that extend horizontally) at C7 were too thin, he needed to jump down to T1 and T2. C7 essentially floats now like a busted kitchen cabinet hinge. I can feel it sometimes when I turn my head moving when it isn’t supposed to. I feel better, but I still hurt. Most of the day I have a dull pain that gets progressively worse until I can lay down. If I look down too much from reading or cooking, it gets bad quickly. Before the surgeries, I wouldn’t feel much pain at all most of the day, but I’d fall down on the ground and cry like a baby if I sneezed. Successive sneezes were awful.

The scar on the back of my neck is pretty awesome. I want a tatoo of a couple battery symbols or “Warranty void if opened by unlicensed technician” next to it. Any ideas?

It still itches often.
It still itches often.

So you know how the doctor asks you to rank your pain on a scale of 1 to 10? I have a new reference point for what a 10 is. Makes you think about what is important in this world.

Metadata vs Folders

I just came across a group post on LinkedIn this morning about the use of folders in SharePoint document libraries. I made a decent response via my phone, but I wanted to make a proper post.

Current best practice for SharePoint – few folders or no folders?

The last time I looked at SharePoint architecture best practices, the thinking was that it was ok to have a few folders, but that the bulk of data should be in one big pile and filtered through metadata views instead of distinct folder locations.

Has that thinking changed, or is the best practice still to use views predominantly?

You can have the best of both worlds. You have at least two audiences for each library, the ones adding to it and the ones retrieving from it. If you have an old school records manager who works with your paper records, ask them about folder structure. I’d say that if your library has folders, you should do it the same way you would on paper. When was the last time you went to a filing cabinet, opened a folder, and saw more folders inside of it? If you have files at the same tier as folders, it is like putting papers on top of the cabinet because you don’t know where they belong. When you create a folder structure that goes nine nested folders deep, you really hide the content from the person looking for it. Even if you assume that anyone needing this could use search, you’d be fooling yourself. Search is smart enough to know that content that is nine nested folders deep is not as relevant as something that is at the root. That piece of content will end up on page 47 of your search results.

Set up the folder structure, then turn off the ability to add folders. Lock the into that structure so you don’t have the folder sprawl that plagues your shared drives. Then, create all of the views based on metadata and remove the folders from the views except for the view for those putting files in there. You can link to that particular view off the Quick Launch and limit who sees it by audiencing the link.

I’d be certain to invest the energy in creating good content types. You might want the PM’s name for all project plans, but you wouldn’t need it for the office picnic flyer.
Don’t just use one big library. Each library should have like content, not the same content types but similar content. You will end up with libraries that use workflows and libraries with more static content. The main the reasons why you split up your content into more than one library is because the content is very different from the other content, permissions vary, and the use of workflows for approvals and such. Unless a workflow is breaking permission inheritance, don’t break permissions inside of the library. It becomes much uglier to manage and can easily lead to orphaned content.

OneDrive Integration Into Your Blogs

I just figured out something cool. I was reading http://thebitsthatbyte.com/ because I met the blog’s author, Kelly Rusk, at SharePoint Saturday Charlotte over the weekend and wanted to check on some stuff he had mentioned. He pointed out in a recent post that one could use intellisense in OneDrive if you go to open up certain file types. I checked by creating a .js file. The built-in text editor is pretty darn good. Then I spotted something else that drove me to make my own post. Inside of a folder in OneDrive, there is an embed link you can hit. It gives you code to insert on any other page to show people the contents of that folder. Here is the folder I’m going to dedicate to all of the big files for this blog. Check it out folks.

See that? You don’t even need to authenticate because it passes a key along with the link.

PSA: InfoPath and Office 2016

Office 2016 was just released today. I was so excited to download and install it. I have my reasons. Just ask those of you who get annoying junk mail notifications in Outlook 2013 how much you hate it. Yeah, Microsoft never fixed it.

I then started looking into how I should upgrade. Most easily done if you have an Office 365 subscription. Ok, cool. I then noticed that the InfoPath icon wasn’t included among the apps. We all know by now that InfoPath has been deprecated. I thought that maybe Microsoft would include the 2013 version with their 2016 suite, since they wouldn’t be upgrading it.

The answer is NO. If you have Office 2013 suite install with InfoPath 2013, that version of InfoPath will get wiped and removed along with your entire Office 2013 suite and upgraded to 2016. In order to create/modify InfoPath forms on Office 2016, you will need to reinstall InfoPath 2013. This will leave you with two “installations” of Office: 2016 and 2013.

Just a friendly PSA. Check here for more info.

Hidden Titles

The primary purpose for me to start this blog was to highlight a few of those war stories I’ve got of saving the day. I will leave the names of the clients I’ve had out of this.

 

So here is a rather recent event. A whole lot of us were on a rather large contract, and the client failed to get paperwork completed on time to keep us on site. We were sent home on mandatory vacation. While on vacation, I learned that there might not be funding for my position after we got back. I spent the time looking for another position. Anyway, three weeks pass and we finally get back to work. A few days later, a guy asks me why he can’t see Title on one of his libraries. After looking at that library for a minute, then others on the same site, then all the way to the Title site column of the whole site collection. Yes, you may have guessed it, Title had been set to hidden and cascaded through the whole site collection.

 

Now, in a happy world, I’d just run to the farm admin and ask him to restore from a backup, but that wasn’t going to be possible. It happened a week after we left the client’s site. It was another three weeks before I learned of this, so all of the documents that had been edited and pages that had been modified would have been lost if we restored from the last good backup. The only other contractor working on SharePoint with me spent seven days going to every single list and library in the site collection, converted all of them to manage content types, and set Title to required, optional, or hidden as required. I spent only two days on the task before I started to work on my last project before leaving to start with a new company.

 

Lessons Learned

  1. Obviously, never screw with the out of the box (OOTB) site columns.
  2. Don’t let qualified people have full control permissions at the root of a site collection. For the record, I had previously stated the one responsible should not have permissions there, but I’m only a contractor.
  3. Your farm admin should have a list of daily tasks and weekly tasks. Somewhere among them should include a series of tests to check for changes via the audit log. You can never expect communication to work properly even if you think you have a good change management process in place, so you need to have someone checking these logs often.
  4. Don’t expect a lot of love from the ones who enabled the person who did this when you fix it. This was a very public airing of dirty laundry. Just do your job and take notes.

SharePoint Irony

I do find it kind of ironic that this blog is not SharePoint hosted (no pun intended, Scott). Blame Microsoft. They can never seem to figure out what they want to do, so I guess this ended up here on WordPress.

If you would have asked me what SharePoint was 4-5 years ago, my honest answer would have been “a Microsoft product”. One two-day crash course and five clients later, I’m thankful to have been able to make a comfortable living developing in SharePoint exclusively. A lot of this is owed to great SharePoint gurus like Scott himself, who was my co-worker and is my colleague.

SharePoint is a great platform for business process automation. It is not a dumping ground for documents (but you can use it for that if you want). SharePoint can be your friend, and it can be your worst nightmare. It is what you make of it. In application, don’t think of things in a SharePoint-ey way, think of it practically. Then, learn and apply SharePoint to fit that practicality.

Oh, and one more thing Scott. It’s spelled “Tardar Sauce“.