Got my MCT (blatant plug alert)

Send to Kindle

A really quick note:

As of last month I am now a Microsoft Certified Trainer, and combined with being a certified MOSS07 technology specialist, hopefully means that my SharePoint bedside manner should be enough to charm and dazzle even your most difficult users, whether senior management or the most scary technical geek.

<blatant plug>

My training style reflects my writing style, so if you like any of the material presented on this blog and feel that it would be useful delivered in person or tailored for your organisation or circumstances, then please do not hesitate to get into contact. 🙂

</blatant plug>

thanks

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Darth Sidious reads the same books as me

Send to Kindle

image Now, readers would know that I really lay on the pop culture references pretty thick. I find it works well and makes ordinary, sometimes mundane, topics much more interesting and easy to explain. I’ve used Brittany Spears, Ikea, Kung Fu, Death metal, Dr Phil and countless others.

But I have never used Star Wars references in my post and probably never will. Why? I would like you to take some time to have a good read of this blog. I am having trouble finding the words to convey how brilliant it is.

http://sithsigma.wordpress.com/

My own company is a play on words on the much hyped/maligned Six Sigma methodologies, but this is so much more clever!

On this blog, both Darth Vader and Darth Sidious offer advice on strategy, project management and general business leadership and management topics. Some absolutely brilliant content there too, all set against the backdrop of what it takes to manage an evil empire. When you think about it, a Death Star is a pretty serious undertaking and to build it on time and on budget takes some pretty impressive management talent. So, despite whether you are an Empire kind of guy, or prefer being rebel scum, you have to concede that Vader and Sidious know how to manage a team. Sure, they made some mistakes (certainly their disaster recovery and risk management strategy were definitely flawed), but most organisations have a misfocussed attitude to security.

Aside from laughing hysterically when reading their material, I am certain that both Sith lords read the same strategy and management books that I do.

Here are some classic quotes..

In this essay on how performance metrics impact employee behaviour, Darth Sidious cites a recent example

…if your compensation system is based on rewarding people for speed, but product or service quality is severely lacking for some reason – even though you’ve mandated quality, it doesn’t make a difference what you mandate if what you’re measuring doesn’t support that goal (or even worse, is opposite to it).

That may seem like an obvious example, but it’s more common than you think. For the Clone Wars we ordered 100M Clones, and we wanted them ready in time to trick Obi Wan, so the Clone factory sacrificed on quality and what we ended up getting was 35% of the Clones being totally useless.

Now *that* is a real-world example that I can relate to!  Here is another gem from Sidious, explaining how the empire maintains a skills inventory to help them understand a team’s strengths and weaknesses.

Say you’re in a team that specializes in using the Force to electrocute captured rebels, or run a Network Engineering team. When it comes to hiring your instinct is to focus on the obvious and primary skill of the team.

Need to fill in an electrocutioner position? Then you’re probably looking for someone who’s learned how to channel the powers of the Force into electricity. Need to fill in a Network engineer position? You probably are looking for a hardcore networking/router/firewall guy.

Probably my favourite article is the Sith version of my "Project Fail" series where Darth Sidious offers advice on strategy, vision and goals. He breaks it down to:

  • Vision
  • Corporate objectives – eg "Increase delivery time of star destroyers by 10% over the next 12 months"
  • Nested Objectives
  • Alignment of Projects
  • Executive/Sith Lord Sponsorship – "if an executive sponsor, Sith Lord, finds out you spent a large amount of galactic credits and it didn’t pay off, now you’re in deep water with no one to support you. A Sith Lord is liable to feed you to a Panna Monster in such a case"
  • ROI

I could go on and on, but I could never do the site justice. The thing I really like about whoever authors this site is that they have managed to find the perfect balance between entertainment value with really insightful and clever messages behind the humour. It is a goal I have been trying to attain in my writing also, but I have to take my hat off to Sith Sigma for nailing it perfectly.

If they would have me I’d write on that site about collaboration under the pseudonym of Jar-Jar Binks 😉

Go take a look now. Tell em Jar-Jar sent you 😉 .

Paul

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Thinking SharePoint Part 4 – Lessons from Kung Fu Panda

Send to Kindle

Article originally published for EndUserSharePoint.com reproduced here.

image

Greetings, my cleverworkarounds kung-fu students. Paul here again to talk once more about Zen and the art of SharePoint. Now I don’t want to appear all arrogant and pretentious, but for this post you can all call me "sifu" :-). I don’t deserve the title in the slightest but since I am writing it you are all forced to live in my fantasy world for a while :-).

I have previously written extensively on SharePoint project failure. In some ways that particular series is just as much about "thinking SharePoint" as this series, but I really do not want to rehash the content there. At the same time, I must confess I was trying to think of a way to round off this particular series of articles with a nice logical conclusion and was lost for awhile. But after watching Kung Fu Panda, I realised exactly how I can end it. So this post is the last in this series – for now anyway.

The thing about using pop culture references as I tend to do is that there is always a risk that some readers may not have seen the movie or heard the album that I refer to. So, if you haven’t seen Kung Fu Panda yet, I want you to visit this website and watch the trailer. http://www.kungfupanda.com/. Having done that, I now want you to read this article, and picture my voice as one of those old kung fu dudes with the long wispy beards offering riddle-like advice that makes no sense. If you can’t picture that, use Yoda instead.

Continue reading

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

IT and the Corporate Immune Mechanism – the "Mother Hen" reflex

Send to Kindle

Recently, I came across the blog of Dux Raymond, a Project Manager, forthcoming author and trainer who looks at SharePoint from a project management perspective. Being rather interested in that area myself, I read his "Empowered by SharePoint" post.

He wrote about the theme of user empowerment that SharePoint provides and made this quote:

Typically, if a project manager wanted a collaborative platform (other than email) to facilitate sharing of project documents, schedule, contacts, and status updates, he or she would need the IT/IS department’s intervention and assistance to set it up. In addition to this, IT/IS would need to define the appropriate access privileges to limit who has access to these project information. Now, realistically, do you think IT/IS will get it done ASAP?

Dux went on to describe the features of SharePoint that can be used to empower users to be more efficient and productive.

The problem with this ideal (which I wholeheartedly agree with by the way) is that there is the problem of the corporate immune mechanism that likes to get in the way of any ideal that disagrees with its own. I wrote about the corporate immune mechanism in my kung-fu themed "You’re not ready" post (check the cool youtube clips of Jackie Chan, Jet Li and Tony Jaa 🙂 ). In that post, I defined the corporate immune mechanism as "the living embodiment of human nature’s resistance to change".

Now you might rightly ask me, "What the hell are you talking about? Why would users resist being empowered?"

The answer is that they are not! In fact, the users are not the problem. Sorry to disappoint you nerds reading this post. The corporate immune mechanism, in many cases, is the very department likely to be pushing the business down the SharePoint path in the first place… 

(cue the suspense music from the movie Jaws)

It is the IT Department!!! Nooooooo! How can these sweet, innocent looking people below be perpetrators of the corporate immune mechanism?

image

Shocked? Appalled at my statement? I can hear the indignant comments now…

  • "What! Us? We are the ones who understand technology" (Luddite IT Manager)
  • "What pills are you taking? – We are the innovators" (VB6 Developer)
  • "Use linux ‘cos Microsoft suck" (Technical Geek)
  • "Shut up and reboot" (Helpdesk Guy)
  • "No, you can’t do that because it’s insecure and I said so" (Security Guy)
  • "Users simply cannot be trusted" (System Administrator downloading mp3s on emule)

20 Years of users

imageLike everything else in this world, IT departments are a product of the experience of the team members and the culture of the organisation. Dealing with users is sometimes not fun. IT pretty much sees the user population as a bunch of rebellious, yet naive teenagers. Leave them alone and they will soon run amok and someone will get hurt. If it happens often enough, the teenagers are grounded and not allowed out of the house, except in controlled circumstances.

So, imagine dealing with rebellious teenagers for 20 years. Is it any wonder IT people are a little messed-up? 🙂

If the information worker revolution and the empowerment that comes with it means the IT administrators are out of the loop, then many IT administrators will push back to ensure that they are in the loop. They can’t help this because it has become a control reflex that I call it the "Mother Hen" reflex.

The mother hen reflex should be understood and not ridiculed, as it is often the user’s past actions that has created the reflex. But once ingrained, the reflex can start to stifle productivity in many different ways. For example, for an employee not being able to operate at full efficiency because they are waiting 2 days for a helpdesk request to be actioned is simply not smart business.

Worse still, a vicious circle emerges. Frustrated with a lack of response, the user will take matters into their own hands to improve their efficiency. But this simply plays into the hands of the mother hen reflex and for IT this reinforces the reason why such controls are needed. You just can’t trust those dog-gone users! More controls required!

So, if you think SharePoint is going to empower you, then you either ensure that the business takes ownership of it, with a sponsor senior enough to take on IT, or you had better start getting really friendly with your IT administrators. Many IT departments would positively have a heart attack, allowing end users the ability to say, modify the look and feel of a SharePoint site, use SharePoint Designer to create a workflow, modify permissions on items in a library, create a sub-site, create lists, modify lists with additional columns and the like.

I think it is a fully justifiable point of view when IT is looked at in isolation to the rest of the gears and pulleys that make up the organisational "machine". In IT’s mind, they are doing the right thing, yet they may very well be doing the organisation and SharePoint a disservice. They are scared that users are going to screw it all up and they will be left with picking up the pieces. But does the cost of IT’s compensation measures justify the real risk in terms of dollars and cents?

A recent example of the mother hen reflex completely going off the rails where inefficiency turned into real-life risk occurred in San Francisco with complete lockout of a fibre optic network by one rogue Cisco administrator. http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/07/18/30FE-sf-network-lockout_1.html. This is an example where in the administrator’s mind, he is being security-conscious, yet ultimately he was the biggest security risk of all.

Closer to SharePoint home, there was a thread on a SharePoint mailing list a month or so ago about managing SharePoint security groups, and the general consensus was that the groups should be set up and managed in Active Directory and then added into SharePoint. I am of the opinion that it is not as clear cut as this. IT generally controls Active Directory so group membership changes would remain in the perpetual 2 day turnaround that is typical of helpdesk SLA for the enterprise organisation.

But consider this. If for example, a project team has a project administrator who is trusted to manage access to all paper records, HR and payroll systems, then I have no problem delegating them the rights to manage a project sub-site or add/remove visitors to the site without having to wait 2 days for the request to get through IT’s helpdesk system. SharePoint provides the necessary audit trails, versioning and recycle bin recovery and the accountability can be pushed out to the project team. A win-win in my book.

Out of rehab

I’ll admit, a few years back I had a scary mother hen reflex. But later I realised that while I did a lot of security policy and compliance work, I was accountable for the IT service, not the information assets provided by that service. If I kept the service running, backed up and provided assurance as to the recoverability, then accountability for the information lay elsewhere.

Sadly, SharePoint does not make any of this easy. Complexity breeds confusion and it is exceptionally difficult to know *everything*. Fear of the unknown also breeds the mother hen reflex too. So, for that reason I am completely sympathetic to why IT departments tend to be very controlling, yet I recognise that it is too inward facing and can actually be damaging to organisational productivity and innovation too.

Unfortunately I don’t have any answers on where the line should be drawn either. That’s a function of many factors. However, what I can tell you is that empowerment is not always guaranteed.

 

Thanks for reading

Paul

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Thinking SharePoint Part 3 – A tale of two clients

Send to Kindle

My third post on "Thinking SharePoint" for www.endusersharepoint.com reproduced here.

Hi all

[Quick reference: Part 1 and Part 2]

If you have followed the first two articles in this series, I have been attempting to talk about SharePoint "head-space". In other words, SharePoint success is so much more a people issue than a technical or architectural one. As a result, it can be a little difficult to write about!

As a MOSS2007 product specialist and architect, I have slowly developed a kind of spider sense that allows me to pick out likely problematic implementations fairly early in the process. This spider sense is most definitely not along the lines of "oh these guys know nothing about application development/security/collaboration/[insert word here]". Often there are excellent, really knowledgeable staff on hand with exemplary credentials. It is instead a feeling that I previously described as "organisational maturity". Want a better explanation than that? How about something like the "oh they are *so* not ready for what they are getting themselves into" factor.

In Part 2, I’ve touched on the potent combination of differing personality types and the different stages of learning along with all of the new SharePoint features and options at your disposal. If you did not read part 2, then I strongly suggest you do so before continuing with this article because I am going to revisit the learning types stuff here.

Another way to describe the "unconsciously incompetent" stage of learning (that sounds much less insulting 😉 ) can be summed up as "you don’t know what you don’t know". The "Ikea guy" example in the last post is a perfect example of low organisational maturity. In my example, the poor unloved Ikea guy turns up at a house to install an Ikea modular storage solution and has to satisfy the conflicting requirements of a family so dysfunctional that the Simpsons seem pretty tame by comparison. It is clear from an outside perspective, that they have called in the "Ikea guy" way too early in the piece and in fact he is completely the wrong guy to call anyway! Wrong guy? Who should we be calling then?

image    image

Who you really need is someone like Carson and the boys from "queer eye for the straight guy" – Either them or Doctor Phil. They might come on a bit strong at first, but they work by winning your trust, building your respect and slowly but surely give you the confidence to change your old, bad habits. Before long the dysfunctional family have turned a corner, to the amazement of yourself and those around you. As an added bonus, you had a lot of fun along the way and your dress sense has improved as your stress levels have dropped 🙂

You still need the Ikea guy, but at least now the family no longer argues so much over which drawer your socks should be stored in!

Of course, the ultimate SharePoint consultant is this mythical person. can deal with your emotional issues *and* install the system! 🙂

philTheIkeaMan (2)

Workshops, workshops!

Where possible, I always undertake SharePoint engagements in an advisory capacity before any time and cost estimates are made. Why? Because invariably, many/most clients start from a position of unconscious incompetence. Not just in term of the product itself, but in terms of a shared understanding of the problem with their colleagues and co-participants. Anyone who has been to a Microsoft sponsored SharePoint seminar and thought that SharePoint is the answer to their prayers is definitely in the first stage of their learning. In fact, when a client wants to skip the advisory stage and get straight into the "just tell me how much it costs", my spider senses tingle…

Thus, I run *plenty* of workshops. I don’t believe that "IT Integrators" who, for example, specialise in Exchange, Cisco networking and firewall type security are overly well suited to perform SharePoint implementations. Equally, I’m not convinced that a "Web Design House" is also particularly suited either. Yes, there is a big technical/architectural component (Ikea guys), but most of the work is in the facilitation, dialogue and requirements gathering stage of the process (Carson/Dr Phil guys). In other words, getting people from that "unconsciously incompetent" phase to "consciously incompetent" stage of learning.

I tend to keep the workshops to no more than two hours in a single day, with a break after an hour for everyone to recharge their brain cells with a jolt of caffeine :-). I also keep the workshops to 4 people or less and split into multiple workshops if there are more than 4 participants.

My goal in these workshops are threefold.

  • Teach some product basics, answer common questions and set the scene
  • Get participants thinking talking about what SharePoint means to them, and what they want to get out of it
  • Assess the personality/competency/maturity level among participants ("unconsciously incompetent" versus "consciously incompetent’)

Achieving these goals usually takes two to three workshops and it is unwise to pack all of those goals into one workshop anyway. The first workshop is all about the product basics (goal 1 above). I do not go into massive detail, just enough so that participants are not flying completely blind with their understanding of the product. Signs of success of this workshop are the shared realisation from participants of the huge potential of the product in certain areas, and an appreciation of the fact that there are a lot of organisational issues that will affect success, and thus it is much more than just whacking in the CD and running SETUP.EXE.

Politics, politics!

I prefer to wait a day or two before the second workshops, as it gives participants a chance to take in the content of the first. When we meet for the second time, I do a quick recap on workshop 1, and then we start talking through requirements, issues, constraints and risks. One sure sign of organisational maturity among participants is how long this workshop takes. This is a factor of the scope of the perceived "problem" to be solved, but more importantly, often this is the first time the participants have actually *talked though* a problem together (aside from previously all agreeing that it is sub-optimal in the first place). It is very easy for these workshop to go over time, or to finish unresolved.

Additionally in this sort of workshops, you can fairly quickly assess the political dynamic of the group (goal 3). Participants always have different agendas or belief on what needs to be done to solve organisational problems. Often participants have locked horns with each-other way before SharePoint came on the scene, and it doesn’t take long to see where the dynamics lie. Understanding this dynamic allows you to tailor your facilitation and teaching approach and build trust and respect among all of the participants.

This can be a frustrating stage among participants, especially while a shared understanding is still being developed. But right here is the root of project failure – not just SharePoint.

What I will do now is tell you briefly about two different client engagements that I was involved in some time back. Both of these client engagements happened at around the same time, and each client happened to be in the same vertical market, although they had nothing to do with each-other. Both were ultimately successful projects in terms of delivery, but one was much more successful in terms of laying a foundation for future projects. If any aspect of these two tales resonate with you, please send a comment through at the end of this article.

Client 1

The first client was a tender that had a fixed time constraint (spider-sense goes gangbusters at this point). However the client had attended one of my seminars where we talked about how to approach a SharePoint project. (The subject matter being a more distilled version of my various posts such as this one). Thus, I had the chance to sit down and have a long chat with the client in an informal environment and felt the theme of our seminar had resonated with them and they had a solid appreciation why we approach SharePoint projects the way we do. 

Despite the very tight time frame I was able to conduct a couple of workshops in two groups and we were able to agree on deliverables that were realistic and achievable. However the workshops were an interesting experience. There were too many people and the group dynamic was clearly political in nature and there was open, sometimes rigorous debate, about specifics of the deliverables. The skill levels varied, as did the agendas. This client also outsourced IT support, so was somewhat light on the ground in terms of infrastructure and application development skills. Thus, we made a conscious decision to stick to SharePoint designer and go out-of-the-box for this initial engagement as we felt that the timeframe and process maturity constraints meant that we would be better served using tools that were easy to make modifications to. We had made this clear (or so we thought ) to the client when we responded to the tender.

By the end of the project two deliverables had expectation mismatches in their functionality. A couple of sticking points were actually how SharePoint was architected as a product and the miscommunication stemmed from a lack of understanding of how the product worked in particular regards. To change the behaviour would require disproportionate custom development work that would very likely be redundant fairly quickly, once users started using the product. Additionally, custom application development for SharePoint adds to governance and they were not yet ‘ready’ to make that leap.

Now it is important to note here that the client was not really at fault. You can hardly blame someone when they "don’t know what they don’t know". The failure was on my part, in that I did not do enough to ensure that we had a shared understanding and full awareness of the constraints of our approach. At the time I thought that we had achieved this milestone, but looking back, it as clear that principally due to the very tight time-frames that we had to operate under, we under-invested in this part of the project.

Fortunately in this case, we were able to agree on workarounds that got the project over the line on-time, made logical sense and did not have any major impact on either party. But the major "lesson learnt" from this project is that we never actually guided the client properly to the "consciously incompetent" stage of their learning.

Client 2

Client 2 was an interesting case. They attended the same seminar as Client 1, principally because a competing integrator had sold them the idea of using SharePoint for their Internet site. Upon seeing the high cost of the licensing, the competing integrator then showed them "all of the other great features" that they would get from investing in SharePoint and overloaded them on recycled Microsoft "6 pillar" marketing material. The client liked all of these new features of course, and thus broadened the scope of the deliverables to help justify the cost.

Result? Even more confusion (and at this point they still had not actually *used* SharePoint). So they attended my seminar for some direction and I was subsequently engaged in an advisory capacity to help them make sense of it all.

I used the workshop approach as described above, and the first workshop was heavy going, because it took a while to sort out all of the marketing fluff from reality. They had been the victim of one too many PowerPoint slide decks and thus jumped around from topic to topic. I answered as best I could, occasionally having to use geek-speak but mostly was able to keep it pitched at the right sort of level. The client then had to reconcile the reality of SharePoint against this overly broad scope that they had created for themselves. It was frustrating for them, and I really felt for them. I even went as far as to offer to discuss things over a beer. (It’s amazing how much more progress you can make over beer 😉 .

A week went by, and the client called me back in. That week they had spent a lot of time soul searching and debating where, when and how SharePoint should be tackled. In the end they had re-examined the corporate strategy, which was a high level, 3 year plan that had been signed off by the organisation previously. They then examined the IT department’s 3 year plan which was developed to support the organisational strategy.

They came to the conclusion, that their external web site was not the place to start, for various reasons. Instead, they identified a much smaller scope project that slotted in perfectly with both the IT department strategy and more importantly, the organisational strategy. They asked me for feedback and I was very enthusiastic in how well they had done, considering the hard-slog workshops from the week before.

At this point, the transition from "unconsciously incompetent" to "consciously incompetent" was well underway

I met with them a few days later. Since the entire team was behind the agreed project, they had talked to the organisation stakeholders, mapped out and documented the process before I had arrived. They also were eager to learn SharePoint, and since the scope of this project was not large and the shared understanding was high, we were able to use this project as the training exercise to learn various concepts from Farm Administration, libraries, lists and columns, SharePoint Designer workflow and InfoPath Forms Services. When we hit an obstacle, we collectively were able to find creative, yet simple ways to get around them.

That smaller scope project was successfully delivered, and the benefits were significant. The team now has a much better understanding of the product, its constraints and limitations. It was now much easier to plan for and tackle the more significant project of web content management (Internet site) as there was a much greater level of shared understanding between participants. They felt more confident in their knowledge of the product, and now feel confident that they would be able to manage the expectations of the organisation.

All in all, it was a great engagement and I came away with a huge respect for that client. More importantly, the relationship continues to this day.

Conclusion

I wonder if the story of the first client is a familiar one to readers, either as being and end-user or being involved in the project itself? 

Certainly the second client had frustrations at the start, as they realised that SharePoint was not the panacea they were looking for, they stopped, took stock and co-operatively reassessed the situation. Unconstrained from a fixed time deadline, they realised that more thought was required. That action potentially saved them a lot of stress and heartache which they would have experienced had they ploughed on ahead with an ambitions project. It has now given them a great foundation to build upon for the future.

Thanks for reading

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Using google to find potentially misconfigured SharePoint sites

Send to Kindle

Those in the security community who have ever performed vulnerability assessment/penetration testing will know of the Google Hacking database. Google is actually a very handy tool to look for potentially vulnerable sites, due to the fact that it will crawl anything it finds. Therefore, if you have misconfigured an externally facing web-based application, at some point the crawler will come along and your misconfiguration will end up in Google’s giant cache.

Extending this risk to SharePoint is not such a stretch. For example, type the following into a Google search…

"view all site content" "sign in" "people and groups"

What do you see?

Scary, huh?

Now to be fair, I have to make some points here.

  • Many of these sites are legitimately meant to be accessible to the public
  • I am not disclosing a SharePoint vulnerability, or any issue with the security of the product. Hence why this is not posted to say, bugtraq and I am not making a big deal of it beyond this post.
  • SharePoint is secure by default in the sense that privileged operations are protected by granular access permissions and anonymous access must be explicitly granted.
  • It is extremely unlikely that you will be able to change anything – as this is read-only anonymous access explicitly granted by the SharePoint administrator. Areas of the site not marked anonymous (e.g site settings) should be safe from modification
  • If there is an error here, then it is human error around configuration of the product.

But as a "bad guy", when you decide to target an organisation, you go through a phase of gathering as much information as possible. Some of these sites expose domain names, user account names and other personal details. Such information can be used to gather additional information. For example, knowing a person’s name, I could set up a fake email address, myspace or facebook account in that person’s name and target their colleagues using social engineering techniques. Using anonymity tools like tor in combination with say, WGET, you could sponge all of the data and documents on such sites for offline analysis.

Documents left inside public document libraries expose internal system names, acronyms and details that paint a fuller picture of the internal organisational set-up. Such information can be used for bogus telephone surveys for the purpose of obtaining more information, targeted Trojans disguised as patches, etc. On occasion, particularly sensitive information can be found within these publicly accessible lists and libraries. (Consider the risk if a data connection library or client list was contained in a site like this).

Additionally, when I see domain names, it gives me a pretty good idea of the topology of the SharePoint infrastructure also. Why? Well, for example, if I see domain names, then people are signing in using their domain accounts. Therefore, the SharePoint server has to be part of the Active Directory and is very likely residing on their internal network and published to the Internet via ISA or some other reverse proxy or port forwarding technique.

All in all, it should be a wake up call to SharePoint administrators about the risks of information disclosure when setting up public-facing SharePoint sites.

Google does not forgive (or forget).

Thanks

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

A neat trick with the publishing feature

Send to Kindle

As I mentioned in my last post, I always security trim SharePoint. A very common issue with a security trimmed SharePoint is the "access denied" message that you receive when trying to activate the "Office SharePoint Server Publishing Infrastructure" site collection feature.

image

There are lots of blog topics about this. Most refer to this one as the definitive source.

Activating Office SharePoint Server Publishing Infrastructure

The issue here is that the publishing feature actually breaks a security rule. When you think about it, activating a site collection feature should only ever modify settings related to that site collection. I previously blogged about how it was bad practice for a site collection feature to modify the web.config files for a given web application.

If you set the scope of this feature at the site collection level, you are basically allowing a site collection administrator to make a change that affects all other site collections in the web application. Uh – does the site collection administrator have access to other site collections? Probably not, so why the hell would you allow them to perform a task that impacts on site collections to which they have no access? You don’t – it breaks the security model.

Well, as it happens, the publishing feature needs to create some SharePoint timer jobs to deal with the scheduling of publishing pages (i.e. Setting the date/time of when a page should be published to the masses). But where are timer jobs edited and managed?

Site Collection Administration! This is a *farm* level operation. Should a site collection administrator have the access rights to add custom timer jobs to the SharePoint farm? Hell, no! that is a farm administrator’s job!

So, is it no surprise then, that the publishing feature barfs when activated by a site collection administrator who has no *farm* level access? (I’ve pasted the error message to the end of this article).

I could whine about how this *should* be done, but instead, I’ll simply tell you the two quickest tricks to fix this issue. Both of these methods do not require changing permissions as per the aforementioned blog.

The first method, is to use STSADM to activate the feature for the site collection. By definition, to use the STSADM command, you have to be logged into the SharePoint server and be a farm administrator. Therefore, running the following command should do the trick.

stsadm -o activatefeature -name PublishingSite -url http://sitecollectionurl

The second method is the one that I use (although it’s less clean). As per normal, I create a web application, and then create a site collection. (Usually the blank template for reasons that I will talk about some other time). But rather than log into the site and activate the publishing feature via site settings, I immediately create a *second*  site collection (e.g /sites/boo).

Remember that I am performing this task via SharePoint central administration, so I have farm level permissions.

When I create this second site collection, I choose the publishing site template. As the name suggests, the publishing site template uses the publishing site feature by default. So in creating this site collection, the SharePoint timer jobs get added to the farm.

I then immediately *delete* this site collection, as it is no longer needed.

Now I can load the originally created site collection and activate the publishing feature. It will work fine, because the timer jobs have already been created, and all of the other goodies that the publishing feature gives you, are scoped at the *site collection* level. Therefore, no more "access denied" messages.

Regards

Paul Culmsee

www.cleverworkarounds.com

 

Error message: (stop reading now – this is for google 🙂

"Feature Activation: Threw an exception, attempting to roll back.  Feature ‘PublishingResources’ (ID: ‘aebc918d-b20f-4a11-a1db-9ed84d79c87e’).  Exception: Microsoft.SharePoint.SPException: Provisioning did not succeed. Details: Failed to provision the scheduling job definitions.  Page scheduling will not succeed. OriginalException: Access denied. —> System.Security.SecurityException: Access denied.     at Microsoft.SharePoint.Administration.SPPersistedObject.Update()     at Microsoft.SharePoint.Administration.SPJobDefinition.Update()     at Microsoft.SharePoint.Administration.SPWorkItemJobDefinition.Update()     at Microsoft.SharePoint.Publishing.Internal.RootProvisioner.<>c__DisplayClass5.<AddSchedulingJobDefinitions>b__4()     at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Good advice hidden in the Infrastructure Update

Send to Kindle

I guess the entire SharePoint world now is aware of the post SP1 "Infrastructure updates" put out by Microsoft recently. Probably the best thing about them are that the flaky "content deployment" feature has had some serious work done on it. (My advice has always been use with extreme caution or avoid it, but now I will have to reassess).

Anyway, that is not what I am writing about. Being a former IT Security consultant, I have always installed SharePoint in a "least privilege" configuration. I use different service accounts for search, farm, SSP, reporting services and web applications. The farm account in particular, is one that needs to be very carefully managed given its control over the heart of SharePoint – the configuration database.

Specifically, the farm account never should have any significant rights on any SharePoint farm server, over and above what it minimally needs (which is some SQL Server rights and some DCOM permission stuff). For what it’s worth, I do not use the Network Service account either, as it is actually more risky than a low privileged domain or local user account.

Developers on the other hand tend to run their boxes as full admin. I have no problem with this, so long as there is a QA or test server that is running least privilege.

However, as always with tightening the screws, there are some potential side effects in doing this. There are occasions when the farm account actually needs to perform a task that requires higher privileges, over and above what it has by default. Upgrading SharePoint from a standard to enterprise license is one such example, and it seems that performing the infrastructure update may be another.

If you take the time to read the installation instructions for the infrastructure update, there is this gem of advice:

To ensure that you have the correct permissions to install the software update and run the SharePoint Products and Technologies Configuration Wizard, we recommend that you add the account for the SharePoint Central Administration v3 application pool identity to the Administrators group on each of the local Web servers and application servers and then log on by using that account

You may wonder why this even matters? After all, it is exceedingly likely that you logged into the server as an administrator or domain administrator anyway. Surely you have all the permission that you need, right?

The answer is that not all update tasks are run by your logged-in account. Although you start the installation using your account, at a certain point during the install, many tasks are performed by the SharePoint Central Administration application. Thus, despite you having administrative permissions, SharePoint (using the farm account) will not have.

So the advice above essentially says, temporarily add the SharePoint farm account to the local administrators group and then log into the server as that user account. Now perform the action as instructed. That way the account that starts the installation is the same account that runs SharePoint and thus we know that we are using the correct account with the correct server privileges.

Once the installation has been completed, you can log out of the farm account and then revoke its administrator access, and we are back to the original locked down configuration.

So keep this in mind when performing farm tasks that are likely to require some privileges at the operating system level. It is a good habit to get into (provided you remember to lock down permissions afterwards 🙂 ).

Cheers

Paul

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

Lots of writing (just not here)

Send to Kindle

Hi all

My poor-old cleverworkarounds blog has been sadly neglected lately (and my numbers are reflecting that too dammit). But I have actually been doing a while lot of writing for other SharePoint online publications, namely EndUserSharePoint and SharePoint Magazine.

The feedback from both has been great and much appreciated. If you haven’t read these articles, then here is your quick reference.

Series 1: Rethinking SharePoint

This is a 4 part series that was a serious attempt to delve into SharePoint headspace. I focused very much on the human/social side of SharePoint projects. I was pretty pleased with how it came out and look forward to the final part being published soon.

Series 2: A tribute to the leave form

This series is an offbeat look at the world of InfoPath Forms Services and SharePoint Designer workflow. Although I am having a bit of fun with this, there is a serious message behind it. While forms services looks terrific in demos, sometimes looks can be deceiving! The trick with this series is that they are also written to cater for a large audience, and that will be quite a challenge when we get into web services and code behind in InfoPath.

I’ve written 4 articles so far and I’d say there could easily be a dozen by the time I am done. The feedback has been really good, so here’s hoping I can deliver the rest!

  • A tribute to the humble “leave form” – Part 1
  • A tribute to the humble “leave form” – Part 2 *not yet released*
  • A tribute to the humble “leave form” – Part 3 *not yet released*
  • A tribute to the humble “leave form” – Part 4 *not yet released*
  • .
  • .
  • A tribute to the humble “leave form” – Part n *not yet written* 🙂

I have a large list of topics to also get well and truly stuck into, so hopefully I’ll have some quality stuff for you fairly soon.

Stay tuned

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle