PowerShell Security Scan With Tree View Output

As I started my work to migrate files from file shares to SharePoint, I realized that I needed to have some sort of scan of the existing structure and security as it is.  I needed this to be friendly enough to hand over to regular users so that they could have an idea of what kind of work needed to be done for migration preparation. 

Since users are familiar with the tree hierarchy I wanted to be able to output something to them that would maintain this look and feel.  I also wanted them to be able to hide sections of the output.  If a large part of the structure is just inheriting permissions, doesn't apply, have been dealt with, or whatever, I wanted them to be able to shut that section down.

PowerShell doesn't really have a good output for tree views.  Sure, tree is around, but it wouldn't serve my needs.  Maybe I just don't know it well enough yet...
I didn't want an Excel output, because it really doesn't have a great tree view.  Again, maybe I just don't know the product well enough.

I chose to create a simple HTML file as the output and use some simple CSS and JavaScript to get the functionality I wanted.  One of the cleanest tree views I have seen comes from W3Schools.com.  They have a great site for this kind of thing and their tree view was exactly what I was looking for.

Once I figured out how to layout the HTML and how the nested unorganized lists would work, the whole thing came together pretty quickly.  PowerShell has some out of the box cmdlets that do the heavy lifting.  I made use of the normal Get-Item and Get-ChildItem cmdlets to get collections of the folder objects, then simply called the Get-Acl cmdlet to get the security of the folder. 
The ACL return object of the Get-Acl cmdlet has a handy property, isinherited, that will let you know if the folder inherits security or has custom security.

The only tricky part of all of this was getting the HTML set up.  The nesting works by having the child items contained in an unorganized list with a "nested" class designation enclosed within the parent's line item.  The parent line item is surrounded by a caret class to attach the JavaScript click functionality.

In deep folder taxonomies, the list nesting and closing can get pretty complex.  I solved this by using three functions...  One that set the parent folder HTML structure, one that closed the parent HTML structure, and one that created the childless folder structure.

When all of the shouting was over, I had a reasonably elegant script that determined if a folder had child items.  If it did, it was designated a parent item and the parent HTML was written.  The child folder collection was then sent to a loop that simply called on the function that determined if it was a parent, and so on.

SharePoint File Migrations - What the Hell am I Getting Myself In To

The File Migration is on in a big way in my company.  All file shares are to be migrated to SharePoint by 12/31/2019.

My company's organisation has Corporate sitting at the top as, essentially, a holding company.  Our divisions, work more like subsidiaries with their IT staff reporting to their local leadership, with no connection to Corporate.  Local does not report to Corporate.  I work for Corporate. 

The majority of our IT staff is purely break/fix.  The divisions are mostly in rural locations.  IT is an afterthought at best.  The IT staff comes down to someone who works at the division's child is "good" at computers.  What does that mean for me...  Well...  To put it bluntly, a lack of professionalism. 

Documentation is non-existent.  The ability to write documentation is... questionable.  Most of these people haven't written anything of significance since High School.  Yet, one of the requirements for the project is that they write a design document that will detail their SharePoint site designs with respect to their internal departments.  They also need to write up a security model.

I refuse to accept that the IT staff is incapable of doing this project.  Difficult, yes.  Outside their wheelhouse, yes.  The trouble I see is that they just won't want to do it.  The project will be labor intensive, and I think it will keep getting pushed to the side.

I'll need away to motivate the staff to complete the project, but how do you motivate a staff that doesn't report to you, doesn't like you, and doesn't particularly feel the need to listen?  On top of that, they are geographically disparate.  I can't throw an end of project pizza party.  I can't recommend bonus money.  I can't even send out McDonald's gift certificates.  One, because most of the towns don't have a McDonald's, and two, company policy prohibits it.

I feel like I'm between a rock and a hard place, and I really should be looking for the exit...  But I'm getting off on the challenge.  If I pull it off, it will be a crowning achievement for me.  Sure it won't look very fancy on a resume, but it will be a diplomatic and technical success...  If I can pull it off.

SharePoint File Share Migrations - User Suck

More of a rant than anything useful...

As an IT professional, when considering any type of migration, you need to have an overriding benefit for that migration.  Fundamentally, is the Juice worth the Squeeze?

When you migrate files to SP, you need to do a few things to ensure that the Juice IS worth the Squeeze. 
What is the first and most fundamental need of users in file share or SP?   Retrieve-ability .   Users need to be able to find what they put in, quickly and easily.

With efficient use of Metadata, SharePoint makes retrieve-ability much more efficient than a file share.  However that comes at a cost.  The user must fill in that metadata.  Users HATE filling in metadata. 

When it comes to users, they love unmanaged data.  A user would rather throw their documents/data in to a single spot and bitch about not being able to find anything, than filling in a few columns of data.

Even more than bitching about not being able to find anything, users love folders.  Users would rather save a copies of the same document to 50 different folders, than save a single document and add a couple of columns of data.

It all comes down to basic human nature.  People have a very hard time with delayed gratification.  The getting a delayed benefit of retrieve-ability against filling in a few columns of data NOW is not seen as something that is practical.  Even when shown actual real-time data showing that the time it takes to retrieve a single document using metadata is 2 to 3 times faster than navigating even a known folder structure, filling in metadata is seen as a waste of time.

BUT what is the overall reason you are migrating to SharePoint?  Most of the time it is because the decision makers see that data showing time savings of 2 to 3 times and WANT that productivity increase.  Along with other added benefits such as in place records retention, easier collaboration and file sharing.
At primary issue, however is that users rarely WANT to do any type of migration.  They are typically TOLD to do the migration from management.  Most often, users must do the migration work in addition to their their normal workload.  This means that no one wants to do the migration, it interferes with their typical day, and the migration isn't just a little bit of work.  It is a LOT of work.  Migration software can only go so far, user interaction is required at some point.

So you end up in this loop: 

1. Users are forced to examine their folder structures and come up with a site design with libraries and security models for their documents.  
2. Metadata is agreed upon and added as content types to libraries.  
3. Pilot migration occurs, users realize the amount of work needed for migration.  
4. Users push back on metadata, demanding that the folder structure just be picked up and moved in to SP.  
5. SharePoint Team pushes back, because they know that moving from one unmanaged data storage system to another unmanaged data storage system will do no one any good, and will likely be worse than when they started.
6. Management sides with users, because, they don't know any better.
7. SP Team does what they can by breaking up folder structure as best they can based on user need in to sites/libraries.
8. Post migration users complain loudly about not being able to find anything.
9. Management comes to SP to find out why users can't find anything.
10. SP team responds to management by saying they should have used metadata
11. Management creates project to look in to metadata usage.
12. Repeat at step 1.

This whole rinse/repeat process is why SharePoint consulting is so much better than SharePoint salary work.  Getting paid by the hour means that however many cycles you want to roll through, it all pays the same, and I'm guaranteed income for a very long time.  As a salaried company person, you get frustrated at the repeat cycle of user bull crap.  You get sick of the constant battling with users over the cost/benefit of metadata over folders.  You get tired of spending hours of your time spinning you wheels, doing it wrong KNOWING you will need to redo the work, then having to swallow your resentment as the same users come back to you saying that SharePoint sucks, and you KNOWING that it is the unmanaged data that sucks.

I imagine it is a lot like an internist that spends a lot of time treating a patient who's root cause of all of their medical issues is their obesity.  They spend time and effort coming up with diet plans and arranging nutritionists and other professionals to help this person out, but having the patient just go out and eat the same crap they have been eating in the past.  Eventually that doctor just says, screw that guy.  That is what your SharePoint people eventually say, and they leave to become consultants.

Rant over.  Time to meet with users about how to migrate their folders to metadata...  Again.