I can see that the learning curve for SharePoint is going to be multifaceted, with admin, application and governance being separate tracks that tend to cross over one another when you least expect it. Never thought my split personality would come in handy. (I’m sooooo putting my cranky, caffeine-deprived personality on governance!)
On the admin side, I watched Todd Klindt’s netcast about– among other things– backup and recovery in SharePoint.
Hmmm…I think we have a script that runs daily to back up SharePoint.
Really, I’m like 90% sure.
OK I should probably check that.
One thing I’m dying to find out: what STSADM commands and/or 3rd party tools are out there and loved by real world SharePointers?
For instance, one of my pet peeves is being able to see that an alert is set up for a specific person on a given list, but not being able to see or modify the details (what day/time is the alert expected to fire? under what conditions?). Heck, I’m the one setting the alerts for other users most of the time, but unless I write down, “FC dept Shared Docs alert – Thurs 10am,” it’s unlikely I’ll remember that setting, which makes troubleshooting it a bear.
Of course, I can just delete all the alerts and start over, but that sends an email that an alert has been created to each user – something else I could do without, since untrained users see the word “Alert” and [I am not joking] assume it is a Homeland Security warning.
BTW, if there is some admin console view or Site Settings area that lets you see details for everyone’s alerts, please tell me. I have poked around and I haven’t stumbled on it yet. I will not even be embarrassed for not having found it and I will give you full credit in the followup post, I swear!
I got excited about the “on the go” videos by Lori Gowin and Laura Rogers. They’re just talking SharePoint and the OOTB solutions available to address specific business needs using SharePoint Designer and/or InfoPath. These are no-code apps, which is where I think I’ll start on the development side. I have a couple of projects that are already spec’d out, and they are pretty typical with the exception of some specific security requirements. (Thanks Lori, for discussing some possible workarounds with me for one of those projects!)
Although SPD is sometimes looked down upon by pure coders, and it obviously does have its limitations, SPD provides something great for the novice developer: you can quickly learn the many options available to you within the SharePoint environment and you can see what those options look like in action before trying to recreate them in code.
Plus, like any program you might write,you don’t reinvent the wheel every time you identify a business need. Chances are good that the problem has been tackled before and there’s a solution out there readily available. If you can complete your basic workflow by using SPD, this frees up valuable development time to concentrate on those needs that are business-quirk specific and require a custom written solution.
I’ve been teaching end user SharePoint for a year or so, so I’m used to the wow factor when people who do the same job in different districts realize they can have an online place to collaborate in a way they only could before by going to a conference. (We had one group considering getting a MySpace account to try to collaborate — needless to say, they were our early adopters!)
But moving towards a point where we can start replacing archaic business processes with solutions in SharePoint? That is like butter when you’ve been a fat free diet…Yeah, buttah, baby!
Ack! Apparently if you lock up SharePoint design too much, nobody will use the rigid system you just created. If you open it up too much, you get a patchwork of sites with no cohesiveness and a good chance that your users will provide you a “click-click-BOOM!” that will take out an entire site collection.
And then there’s the issue of scalability and Service Level Agreements (SLAs). Would you care for an antacid?
This is a more convoluted concept than I’m used to dealing with, and the more I try to compartmentalize it, the more heads Hydra grows. Usually, I’m meeting with a distinct group of users, discussing their business process, and developing a method to improve not only the delivery of the process but the process itself. Nice and defined. Not so with an enterprise SharePoint solution.
Ours is the first state government agency to have SharePoint, although there is much interest in it among the other agencies. Having seen it, we have sister agencies wanting access to our resources. This is not 2+2 = 4. It’s 2 to the second power. OK, I just realized that is also 4. Maybe I should avoid the math analogies…but stick with me.
What I’m trying to say is that SharePoint is not just a fancy file server. Its social networking and knowledge management aspects make its growth not linear but exponential. When you allow new users, you have to take their content and their social contacts into consideration. And those considerations tax your resources. Just like in-laws.
So far our answer has been: “We don’t have the ability to have out-of-network users yet.” But as I look into Forms Based Authentication for our in-the-agency-but-not-on-the-network users, we must address the possibility of outside users, and governing that will be one of the bigger considerations as we go forward.