Woody Windischman

Dec-172011

Changing Times

Going (Micro)Soft on You!

Just a quick note to let you know that you're going to notice a few changes to this blog over the coming weeks. The big news is...

I've officially joined Microsoft as a full-time employee!

That's going to bring with it a number of ramifications, the first of which is, I can no longer call myself an MVP. (The first rule of the MVP program is that you must be independent of Microsoft, so obviously I no longer qualify for that...) That doesn't mean that I won't still be providing tips and insights into SharePoint products and technologies, or helping out at conferences. In fact, it doesn't mean a lot for the content of this blog. I do, however, need to make sure people know I work for Microsoft now.

You might want to take a fresh peek at The Four disclaimers. They still hold true - especially the part about this blog NOT being the official word of any company, including Microsoft, unless otherwise specified.

I'm still settling into my new role with Microsoft Consulting Services, so I might be a bit quiet for a little while, but rest assured, (to quote the great Ahhnolld...) "I'll be Back!"


Published: Dec-17-11 | 0 Comments | 0 Links to this post
Tagged as:

Oct-282011

The Fractal Nature of SharePoint

The Closer You Look, the More Complex it Gets...

Over the years, there have been many analogies proposed to help people understand the sheer depth and breadth of SharePoint. Application, Platform, Pie wedges, Donuts, Layers like an onion, Shimmer ("Floor wax and a dessert topping!"). A few years ago, I used the parable of "The Blind Men and the Elephant", and that was looking at the much simpler (relatively speaking) SharePoint 2003!!

Today, SharePoint Server 2010 is orders of magnitude more comprehensive. At the most superficial level, you can look at the whole of SharePoint, and see organization and structure. The key areas are fairly easy to identify, but maybe a little fuzzy around the edges. Consider the image below, which represents the "complete" Mandelbrot Set - the classic fractal example.

Mapping this to SharePoint, you might see the large, two-lobed central area representing the Collaboration and Content Management features, the large ball to the left as social, and other balls representing Excel Services, Access Services, Search, etc...

But when you get closer, and start exploring some of the deeper capabilities, things don't get any simpler. Let's say you want to start exploring the integration of social tagging with content management, so you zoom in on the area just above the center of the image, between the two larger segments. Suddenly you open up a whole new world of options in API's, storage requirements, user interactions with news feeds and tag clouds, managed metadata and tagging external content - all in just that one small area of SharePoint functionality!

This same expansion of detail and complexity occurs virtually anywhere you look. And although every area you zoom into is clearly related to the whole, each has its own variations in the detail. This is why I am using fractals, rather than layers, to describe the depth of SharePoint. While each aspect has levels of functionality (from basic web UI to development APIs), each set of levels is slightly different. The social APIs look different from the search APIs, which are different from the publishing APIs.

That's why it is so hard to find anyone who knows "everything" about SharePoint - it can't be done. People tend to disappear into whatever rabbit hole they find most interesting. Now that doesn't mean that a single person can't know a lot about many different areas. But, you can pretty much guarantee that they don't know everything about everything. There is a very strong tendency to specialize, and even the specialists are (if they're worth their salt) constantly learning.

Oh, and just so you know, the detail image at the top of this article is about the same fraction of the image immediately above as that image is of the entire set!

Note: The fractal images in this article are derived from those in the Wikipedia article on Fractals, and used under the Creative Commons Attribution-Share Alike 2.5 Generic license. They were originally created by Wolfgang Beyer with the program Ultra Fractal 3.


Published: Oct-28-11 | 1 Comment | 0 Links to this post
Tagged as: General, SharePoint 2010

Sep-222011

Governing SharePoint Designer

wpe4A Book Excerpt from “Beginning SharePoint Designer 2010

SharePoint Designer provides a great deal of customizing power to its users. In some environments, particularly in an enterprise, giving all users access to this level of power may not be appropriate. To address this, SharePoint allows system administrators and site owners to configure different levels of access for users of SharePoint Designer.

First and foremost in the governance of SharePoint Designer is the proper application of regular security roles to a SharePoint site. Quite simply, even if a user downloads and installs SharePoint Designer, he cannot use it to make any changes to a site he would not otherwise be permitted to make. For example, a typical user in the Member role cannot change themes or master pages, or modify the schema of a list or library. SharePoint Designer would not suddenly enable him to do so. A user would need to be in (for example) the Web Designer or Administrator role on the site in order to make such changes, regardless of any tool he has installed.

In SharePoint 2010, you also have the settings for directly managing the use of SharePoint Designer, irrespective of the regular security of a site. These settings allow or prevent access to certain features by users of SharePoint Designer.

The SharePoint Designer controls screen is shown below

clip_image002

This page is accessible at different levels within SharePoint, depending upon the scope over which control is to be exerted. You can set these options at the web application or site collection level. If SharePoint Designer or one of its features is blocked at the web application level, it cannot be overridden by a site collection owner. Nevertheless, a site collection owner can invoke tighter restrictions than are set at the web application.

Note: Restrictions implemented at the site collection level impact most users, but do not apply to the site collection administrators themselves.

Regardless of which method or methods you use to restrict SharePoint Designer, your choices will be reflected in the experience presented to the users. The user interface of SharePoint Designer is security trimmed. This means that users are only shown the functions that they have the right to see or control. This figure shows a Site Objects list with all the SharePoint Designer options enabled (the default state).

clip_image003

Compare to the figure below, which is the same site with the options disabled.

clip_image004

Observe that access to the Master Pages gallery and direct access to the site files are not visible in the restricted site. Other elements throughout the user interface, such as context menus, are similarly trimmed.


Aug-222011

Calling All People

wpe4Which Way did They Go?

One of the big attractions (and honestly, biggest fears) of SharePoint for overworked Network Administrators is its ability to delegate permissions management to site collection owners. For purposes of this article, I'm going to gloss over the details of where users are coming from. Suffice to say that they can come from Active directory, or any number of other sources. I'm also not going to talk about breaking inheritance, or anything like that. Instead, I'm going to show you where to find a very useful tool.

Generally speaking, if you have groups available, you want to use them to apply permissions in SharePoint. For example, you might put a network (Active Directory) group into one of the default SharePoint groups. Although it isn't an ideal practice, on an Intranet, it is common to apply a base level of permissions to anyone who has logged into your network:
image

Once users log in and start doing things, they leave a trail of things they have touched, and thus show up as users in SharePoint. On SharePoint 2007, you had an easy to see option to list who had actually done things on your site. This was the "All Users" view. Unfortunately, in SharePoint 2010, there is no obvious way to access this same information. In fact, there are several types of users who you can't readily see:

  • Individuals who are members of Windows groups (such as Authenticated Users above).
  • Site Collection Administrators
  • People given permissions through Web Application policies

The good news is, the information is still there. To get to it, open any group in People and Groups:

image

Then, in the URL, change the "MembershipGroupId" to zero:

image

This will result in the classic "All People" view showing up, including every user who has made updates to your site!

image

A Word of Caution

Although this view is very useful, there are probably good reasons that it was suppressed in SharePoint 2010. The most likely has to do with a classic SharePoint foible - the so-called"2000 item limit". While that is not (and never was) truly a "limit", the fact is that when lists grow to many thousands of items, rendering views can get pretty slow.

SharePoint 2010 has made great strides in working around this issue compared to SharePoint 2007, but there are still some performance constraints when rendering large lists. Given the importance of the Users list, having it locked during a large read could be "a very bad thing." In a large environment, you could have tens (or hundreds) of thousands of people accessing a singe site collection, meaning tens (or hundreds) of thousands of items in the Users list. Attempting to render an unfiltered view of "All People" in such a case could be disastrous.

So, now that you know how to find the All People view, you need to treat it like a sharp knife or a power tool. Handle with Care!