Let's consider today's entry to be an addendum to my two-part look at how to create a new SharePoint group which concluded yesterday, shall we?  As regular rears will no doubt recall, that episode ended in shame for me ... not with the creation of a new group as intended, but with an unsightly error message instead.  Needless to say, I knew that I had to get to the bottom of that error message today before I could move on to another topic, and I'm happy to report that I have done just that.

As I noted yesterday, the error message that I received -which was, I should mention, the first error message I can recall ever having seen in my 6 months as a SharePoint user- was, "The security validation for this page has timed out."  What I didn't mention or, in truth, take much note of myself in my disbelief at seeing an error message in the first place, was that there was another sentence in the error message which preceded the following not-at-all helpful to an end user codespeak:

at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateMembers(String bstrUrl, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bSendEmail) at Microsoft.SharePoint.Library.SPRequest.UpdateMembers(String bstrUrl, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bSendEmail)

As it turned out, I should have paid closer attention to both sentences of the error message which were written in English (as opposed to the multiple lines written in Code) but, if I had done so, I probably wouldn't be writing this today since I'd likely have written off the error as being my fault in the first place.  Which, by the way, it kind of was, since it was a timeout error, and since I was going through the process of creating the group while I was writing the blog entry, it's understandable that the operation would have timed out by the time I finally got around to hitting the Create button.  Still, I submit that those unnecessary lines of code sent me into a bit of a panic, and that my comprehension of the second sentence in English was compromised as a result. 

And so, when I revisited the scene of the crime with a cooler head earlier today, there was the sentence which would prove to be my salvation (and yes, when I say "there it was," I really mean, "there it was, where it had been all the time"):

Click Back in your Web browser, refresh the page, and try your operation again.

Guess which clause I had missed in my haste yesterday?  It was the second one, "refresh the page."  Guess how important that step is?  Muy importante.  As in, if you don't refresh the page, you're doomed to see the same error message for eternity.  Yes, refreshing the page means that all of your carefully considered group creation decisions will be wiped clean and you'll have to start from scratch, but once you've done so, you (or your designated group/owner) will be be the proud owner of a new SharePoint group, like this one:

And that sure beats staring at an error message for eternity, doesn't it?

When we left off yesterday, we had just arrived at the (create a) New Group page, and were on the very cusp of beginning to make the series of decisions required to create a new SharePoint group.  Join me today as we step through those decisions together, and emerge victorious with the creation of a new SharePoint group.  Please hold your applause until the end.

There are five decisions to be made in total, and in the images I've provided below, I'm depicting the default appearance of each field, which is why some fields will be blank.  As with most SharePoint "create" actions, the first decision is simply assigning a name and description.  In the case of a new group, the description is labeled as an About Me description.  Despite that somewhat misleading nomenclature, however, the "me" in question refers to the group itself, and not the creator of the group:

Next on the hit parade is the Owner field.  There can only be one owner, but the owner needn't be an individual - it can be another group.  As I learned from the instructors at Mindsharp, the best practice recommendation in this case is to not leave yourself as the owner (which is the default behavior, as shown below), but to create a group for this purpose.  This way, at least one other person has ownership rights ... just in case, y'know, you were to get hit by a bus or something.  Note that next to the input field, you're provided with the standard Check Names and Browse options which should be familiar to most Outlook users:

Group Settings is the next decision you have to make, and this one is a twofer.  The first decision has to do with who can see the members of this group, and your choices are Group Members, or Everyone, with the choices presented as radio buttons.  (Note to self:  Hey, look at that!  Now go update Friday's post in which I was speculating about this very thing.)  The second decision here determines who has the rights to edit the group's membership:  only the Group Owner, or all Group Members?:

Next up is the Membership Requests decision-making process.  The first decision is whether to permit potential new group members to request to join (or existing group members to request to leave) the group.  The second decision is whether to auto-accept these requests or not.  Note that enabling auto-accept immediately and automatically grants all such requests ... and grants new members the same permissions assigned to existing group members.  Requests are sent to the email address provided in the membership requests input field and, as you can see, by default the email address provided is that of the group creator.  Naturally, this field becomes configurable should you choose Yes for either of the requests options:

The final decision in the group creation process is assigning permissions to group members.  The permissions you choose will apply to all group members, and you'll make your choice by choosing to mark one of the available checkboxes, ranging in permissions from Full Control (basically, the King) all the way down to View Only (basically, the peasant), and everything in between.  Surprisingly, I seem to be able to select more than one checkbox in my MOSS environment, but presumably only one such selection can be honored:

The view site permission assignments hyperlink pictured above will take you to the Site Permissions page, which will show a list of groups and users with access to the site in which you're creating the new group, and their current level of permissions.

And wouldn't you know it?  For my hubris in announcing that we would be emerging victorious with the creation of a new SharePoint group today, I have been punished with the following error message:  "The security validation for this page has timed out."

Oh, SharePoint, why must you smite me so?

Friday's blog topic, detailing where to find and modify existing groups in a SharePoint site caused me to go back and review a previous entry wherein I addressed SharePoint groups.  Which, in turn, caused me to realize that I might have misspoken in that previous entry when I said, based on what we'll charitably call a not entirely accurate assumption, that SharePoint group creation wasn't likely to apply to most end users. 

What was the inaccurate assumption which led to such a gaffe?  Well, it happened because I didn't have permissions to create a group within the main Bamboo corporate portal, and I (foolishly) extrapolated from there that I must not have permissions to create groups throughout our site collection, with the sole exception being my My Site.  Yes, it's kind of embarrassing to admit this but, hey, I figure it's all part of "growing up" in public.  Also, what's a mistake but an opportunity to learn, right?

Needless to say, I've just come to the realization that I actually do have the ability to create a new group within our portal ... just not on the top site. 

So, might you be able to do the same within your portal? 

Maybe. 

The first thing you'll need to determine is whether you have the requisite permissions to create a new group on the site where you hope to do so.  For example, I lack the necessary permissions to create a new group at the top level of our portal, but what I've now discovered (after having first thinking it through, which clearly I had failed to do when preparing that earlier column) is that I do have access to create new groups in my team's site, which exists as a subsite within the Bamboo corporate portal.

Having learned my lesson regarding assumptions, I did the research this time and discovered that only users with full control to a site possess the ability to create groups.  For information on pretty much all of your SharePoint permissions-related needs, I recommend checking out this Microsoft Office Online page on SharePoint permission levels and their associated permissions.

So, from within a site where you've got full control, and where you wish to create your new group, you begin by selecting the trusty Site Settings menu option under the Site Actions dropdown:

Hint: If your Site Actions dropdown doesn't have a Site Settings menu item, you lack the necessary permissions to create a group on that particular site.

On the resulting Site Settings page, select the People and groups hyperlink under the Users and Permissions heading:

The resulting page will be the People and Groups page and, as mentioned on Friday, you'll notice options to display lists of both existing people and existing groups in the Quick Launch.  To create a new group within your site, select one of the existing groups in your Quick Launch and simply click the New dropdown button, which (in my MOSS environment), only has one option, New Group:

(Note:  You may also create a new group from within the context of one of the All People listings in the Quick Launch bar.  In this case, the New dropdown has two menu items, with Add Users appearing in addition to New Group.)

Clicking that New Group menu item will render the New Group page, where you'll be presented with a series of decisions to make regarding your new group and its membership.   Tune in tomorrow when we'll walk through those individual selections step by step, and we shall emerge victorious, having created a new SharePoint group.

Continuing my efforts to perform the due diligence necessary to answer my SharePoint Blank mailbag (hmm, maybe I should start incorporating that into the title for these posts?), today's question came in from kayroxx in response to an entry on SharePoint group creation:

So how do you actually look into a SharePoint group to see who is in that particular group? Where do you even go to see that group at all?

It's been a heck of a week for me, so I'm going to cut myself a little bit of slack for the fact that it took me an embarrassing amount of time to arrive at the answer to kayroxx's question.  Why was it embarrassing?  Well, let's just say that, by the time I arrived at the answer, I realized that it was something I had actually learned in Mindsharp's Power End User summit months ago ... but since it's not something I've had cause to use in my day-to-day operations (and, thus, haven't yet documented here), I'd forgotten that I actually knew the answer.  D'oh!

So, in my MOSS environment (which, by the way, was also the environment used in the aforementioned Mindsharp course), the path to ultimately answering kayroxx's question began by navigating to our team portal, i.e., a site to which I knew that I had a reasonable number of permissions, and clicking the Site Settings menu option on the Site Actions dropdown:

Next, I selected the People and groups hyperlink under the Users and Permissions heading:

Having clicked that hyperlink, the resulting People and Groups page is a veritable one-stop shop for all of the individual users, and all of the existing groups, on the site.  Conveniently, they appear listed under All Groups and All People links in the Quick Launch, and clicking the appropriate links will expand that section within the Quick Launch.  Selecting an individual group will display the members of that group in the page. 

Well, doing so will display the group members with one caveat:  A little clicking around on the Groups links within our corporate portal quickly revealed to me that it's not permitted for just anyone to view the memberships of all groups, as permissions are required in order to do so.  My (not entirely scientific but, I think, reasonably conclusive) research indicates that you must be a member of a given group in order for to be able to view the members of said group and their permissions within the group.  Unless you are a member of a given group, you will only be able to see the members of a group if the group creator chose to  make that group's membership visible to Everyone (i.e., all site users), as opposed to being visible to Group Members only.

Unfortunately, I don't think there's a handy way to see, at a glance, all groups to which you're a member, but if I should learn of one, I'll certainly let you know.  Of course, if you know of such a feature, by all means, do feel free to lay that sweet, sweet knowledge on me.  Cheers.

One of the unanticipated effects of Mark Miller's recent (and much appreciated) plugging of SharePoint Blank over in EndUserSharePoint has been the sharp uptick in the number of questions that I've been fielding in the comments section of older blog entries.  Unfortunately, quite a few of these questions rolled in over the past few days while I was, far more unfortunately, out of the office due to a death in the family.  I'm honored to be asked these types of questions, especially since there's an implied assumption that I might actually know the answers.  Sometimes I do know the answers, but I'm a card-carrying end user whose SharePoint learning is a day-to-day process, so I generally don't know the answer off the top of my head.  I am, however, more than happy to seek out the answer for you, and the fact that doing so also increases my own SharePoint knowledge is the icing on the cake.  Thus, I'll be dedicating the next few days to playing catch-up on my backlog of questions, diligently researching the questions and, to the best of my ability, documenting my findings here.

Two questions came in over the last few days on my Editing Columns in a SharePoint Document Library post from early September, so it only seems right that I mark my return to the blog with a "two-for-one special" by tackling them both today.

First up, Neevarp asks:

I tried to create a column for a document library and it sets itself to be a Read Only column, I am unable to change the type. How can I cange its type to a non read only type so that users can update the column information?

I didn't recall being presented with an option between read only or not when I created a custom column so, following my own footsteps, I began looking into this by creating a new column in an existing document library.  Sure enough, in my (MOSS) environment, there's no mention of read only status (or not) when creating a column but, in my environment, the default is for column data to be editable, as opposed to being read only.  The plot thickens, no?  Off a-Googling I went.  From what I've discovered, the experience in my environment appears to be the norm, in that custom columns should be editable unless explicit steps have been taken to make them not so.  I arrived at this decision after I discovered a discussion on eggheadcafe which explains how a Sys Admin might go about making column data read only to end users.  Check it out, and if I'm misinterpreting anything, please correct me in the comments but, from what I tell, it sounds like a conscious decision has been made by your Sys Admin to force custom column data to be read only.  You might wish to consult your Administrator and inquire as to why this decision was made and, as appropriate, respectfully request that the policy be revisited.

Next up, we have Anton Tomassen, who asks:

Is it possible to edit the "created by" column in SharePoint?  I will populate a list with data but the created by column then has my details in it.  I want it to have unique usernames of the people in my AD in order that I can set the view only to show the row in the list that belongs to the logged on user.

Since I didn't have a Created by column in any of my existing document libraries (the Modified by column is the standard at Bamboo), I began my investigation by creating a new view for an existing library, and adding a Created by column.  Alas, when clicking the dropdown menu associated with the newly created column, the only available options involved ordering and filtering:

So it was off to Google once more and, in this case, props must go to Sowmyan's SharePoint Developer Blog for the post entitled, Can we update the values of "Created By", "Modified By" columns in SharePoint lists?  In this post, Sowmyan answers, in part, "Of course, you can. Created By & Modified By columns are 'Person or Group' type columns. In SharePoint all the lists have these columns by default. You can't update the values of these columns from UI. But, you can do it through SharePoint APIs."  Best of all, Sowmyan helpfully provides a .NET code snippet which will make it possible to update these values.  Needless to say, this is hardly end user-level functionality, but I'd recommend that you consider directing your Sys Admin to Sowmyan's code snippet and asking nicely if this functionality is something that might be incorporated in your site.

I hope these answers were helpful, and that you'll both be able to leverage my findings towards achieving your goals.  If you're so inclined, please report back and let me know how everything worked out. 

Before we pick up with the sequel to yesterday's post on how to add a My SharePoint Sites Web Part to your site, I'd like to acknowledge the mighty Mark Miller of EndUserSharePoint.com for his gentle suggestion that I mention that this particular Web Part is a MOSS-only feature.  Since I'm working in a MOSS environment, and since pretty much everything in SharePoint is new to me, I sometimes forget to make the MOSS/WSS distinction (when applicable).  Mark's comment on yesterday's post served as ample reminder that I need to bear this fact in mind when I'm documenting my adventures in SharePoint.  Cheers, Mark.

When we left off yesterday, I had successfully added a My SharePoint Sites Web Part to my My Site:

I have since confirmed that, per Microsoft, "The SharePoint Sites Web Part automatically displays a list of five sites of which you are a member."   Upon seeing the default tabs that had automatically been chosen for me, I realized straightaway that there were some changes that I wanted to make to the appearance of the Web Part.  To wit, I wanted to delete the test tab since it linked to outdated test content, and I wanted to add a new tab which would link to my team's site on the portal.

Deleting the unnecessary test tab proved to be a simple two-step process.  As it turns out, the navigational tabs in the My SharePoint Sites Web Part offer dropdown menus which feature two options: Hide, and Delete:

Since I knew I wouldn't need that test tab for any reason going forward, it was the Delete option that I selected.  Take note:  Deletion is immediate.  There is no "are you sure?" messaging or the like here, and as soon as you click Delete, your site will immediately refresh with the revised version of the Web Part (i.e., minus the deleted tab).

Adding a new site tab to the My SharePoint Sites Web Part is almost as easy as deleting one though, so even if you mistakenly delete a tab, it's hardly the end of the world.  First, select the dropdown menu associated with the Sites tab which appears at the extreme left of your navigational tabs, and you'll see that New Site Tab is one of the two available menu items.  Click that option to begin creating your new site tab:

Upon clicking the New Site Tab button, your site will refresh with the Create a new site tab UI:

By default, the Select Sites from Membership list radio button option is selected, and the first item in the memberships list dropdown menu will appear highlighted.  Since the first item in my list wasn't the site that I wanted, I scrolled through the list until I found the desired entry, the Online Operations listing pictured above.  As you can see, however, you're not limited to the items which automatically appear in your Membership list menu - you also have the option of manually entering the Site URL and Site Name to create your new tab.

Since I found the site I wanted in my Membership list though, all I needed to do to create my new tab was to click the Create button, and voila, I was the master of my (revised, tab) domain!:

As I mentioned in yesterday's post, it was while getting started with Mindsharp's CBT courseware for end users that I discovered the existence of the My SharePoint Sites Web Part.  I might add that I knew straightaway that this was a Web Part that I wanted for my My Site. As promised, today's post is going to provide a step-by-step guide to adding the My SharePoint Sites Web Part to your site.

By way of a reminder, what this Web Part does is aggregate any and all content that you have authored/uploaded (from across multiple sites within your site collection), and presents that content to you in a cleanly designed Web Part which uses a tabbed user interface.  I dig it the most, and I think you will too.

So how can you get a My SharePoint Sites Web Part of your very own, and be the envy of all your colleagues?  It's simple.  First, from within the site where you want to create the Web Part (I added it to my My Site which, come to think of it, may in fact be the most logical location for this Web Part), select the Edit Page menu option from the Site Actions dropdown button:

On the resulting Edit Mode display of your page, choose the Zone where you'd like to add the Web Part.  I'd recommend adding it to whichever Zone provides you the most width, since that will give you room to grow in terms of adding tabs for multiple sites.  Once you've chosen a Zone, click the Add a Web Part bar in that Zone:

In the resulting Add Web Parts popup, locate My SharePoint Sites listing, noting that you may need to scroll and/or expand certain areas to find it.  I found it under the Content Rollup heading on our portal.  Having located it within the list, click the associated checkbox for the Web Part:

Once you've placed a check in the checkbox, and clicked the Add button at the bottom right of the popup, your page will refresh (in Edit Mode) with your new My SharePoint Sites Web Part in place.  I suspect that, as was my experience, you'll find several default site tabs will appear automatically, with the tab for the site on which you've added the Web Part preselected:

Right off the bat, I saw a couple of changes that I wanted to make.  Specifically, those changes involved removing the test tab, and adding a tab for my team's site. 

Tune in tomorrow, and I'll give you the full scoop on how to accomplish those very tasks. 

Our friends at Mindsharp recently provided us with their End User Training for MOSS Computer Based Training (CBT) courseware.  Given my excellent experience attending the in-person version, Mindsharp's Power End User training, over the summer, I've been anxious to dive in and check out their CBT offerings.  I finally got a chance to do just that earlier today.

As it turned out, it would be more accurate to say that I dipped my toe as opposed to diving in, since I only spent a short while appreciating the quality of the presentation and the slick user interface.  In addition to the high quality of the content itself, Mindsharp's CBT presentation boasts seamless video paired with engaging audio, and easy-to-use player controls:

The reason I only spent a short while taking in the presentation itself is that I jumped right into the Features to Track Content in My Site module.  Within a couple of minutes, I was hearing about a heretofore unexplored (by me, anyway) Web Part called the SharePoint Sites Web Part (aka, the My SharePoint Sites Web Part, which is how it appeared to me when I hopped over to our portal and went looking for it).

From the CBT, I had learned that the My SharePoint Sites Web Part "allows users to manage content they have contributed to multiple sites by aggregating that information in a single location."  Once I'd seen (and heard) this, I knew I had to get my hands on the Web Part right away, and so I commenced to do just that.

I'm going to spend tomorrow's blog detailing the setup and customization of the My SharePoint Sites Web Part, but I wanted to mention the organic process that led me to it via Mindsharp's CBT because it underscores one of the benefits of the CBT model.  As you can probably see from the process I've described, the at-your-fingertips nature of the CBT training (and the ability to easily pause/hold your place at any point within a given lesson) allows you to travel a straight path from learning something new to actively demonstrating that newfound knowledge in your SharePoint portal.  And since you're moving at your own pace, you can tailor your learning to virtually any available block of time.  After all, it only took me a couple of minutes to learn about a new-to-me Web Part, realize that I wanted to try out right away, and then within another couple of minutes, I had installed and modified the Web Part on my My Site.  Needless to say, these are benefits that even instructor-led training can't always offer, and they are to be celebrated.

You can bet I'll be devoting a great deal more time to Mindsharp's CBT in future blogs, but I wanted to share these initial impressions with you straight "out of the box," as it were.

A question came in yesterday in the form of a comment on an older blog entry concerning best practices for a SharePoint document library.  Paul asked, "Can I allow people to Read-only and not be able to check out a document?"  Given that I'm still learning SharePoint myself, I wasn't about to answer this question without first having gone through the necessary steps to verify that what I thought was the answer was indeed the correct answer.

Happily, I was correct in that it is possible to mark the entire contents of a document library as Read-only, by designating it as such for a specified user or group of users.   To do so, from within the document library in question, select the Document Library Settings menu item under the Settings dropdown:

On the resulting Customize page, click the Permissions for this document library hyperlink, under the Permissions and Management heading:

The resulting Permissions page will show the existing users and user groups, along with their existing permissions within the document library:

Note that, in the example above, the authenticated users group is already limited to Read access.  If I wanted to also limit the System Account user to Read-only access, I'd click the checkbox next to that user's name, and then select Edit User Permissions from the Actions dropdown menu:

On the resulting Edit Permissions page, you'll see the full range of permissions that can be assigned.  As you can see in the image below, Read - Can view only appears among the available options.  It's clicking that Read checkbox (and then the OK button) that will change the permission level of the selected user to Read-only for the contents of the document library:

It's time to close the books on my five-part investigation into the integration (or lack thereof) between a SharePoint Meeting Workspace and its associated calendar events.  Regular readers may recall that we left off on Friday with the successful creation of a Meeting Workspace (in conjunction with a recurring calendar event), and now it's time to bring it all back home.

Since I'm still a relative newbie in the SharePoint game, I'm not embarrassed to admit that it wasn't until I had created a Meeting Workspace and began looking into the specific relationship between the Meeting Workspace and its associated recurring calendar event that I was able to even begin to understand the question that had set my investigation in motion.  It was only upon clicking around in my Meeting Workspace and, in particular, clicking the Manage Attendees and Add New [Agenda] Item hyperlinks (since these were the specific areas that I was looking into), that I came to the conclusion that there doesn't seem to be any configurable manner of updating these items within the basic template of a Meeting Workspace and also having those updates reflected in the associated calendar event.

Having discovered those limitations, however, I should also point out that what you can do within the Meeting Workspace itself is make changes to the attendees and agendas specific to an individual instance of a recurring event.  It's just that those updates are specific to the Meeting Workspace and aren't synched with the associated calendar event. I should also point out that, as shown at left, there is a handy list of your associated recurring meeting dates provided to you in the left rail of the Meeting Workspace.  Clicking any of those hyperlinked dates will allow you to easily mangage the specifics of that particular day's instance of your ongoing event in terms of attendees, agendas, etc.

It was around this time that I began to suspect that the desired functionality was probably attainable, but that it would likely involve third-party providers.  Furthermore, I suspected that our own List Rollup Web Part could likely be a key player in providing such a solution.  That said, I also knew that I was out of my league at this point, and the time had come to engage an expert, so I reached out to Jeff Kozloff from our Solutions Team for a consultation.  I brought Jeff up to date on both my findings and my suspicions, which led to Jeff's immediately positing the manner in which such an integration between a Meeting Workspace and its associated calendar events might be accomplished.  I was pleased to have my suspicion of List Rollup's key role in such an operation confirmed but, at the same time, I knew that Jeff was describing a level of integration that I also knew was beyond my own humble SharePointing abilities.  And so, having already learned plenty in the course of my investigation, I thanked Jeff for his time (and for his agreeing to carry on the discussion in the Bamboo Calendaring forum), and set about plotting my five-part series on the matter.

This has been part five of a special collector's item mini-series ... collect all five!

Part One: SharePoint Calendars & Meeting Workspace Integration

Part Two: Create a New SharePoint Calendar

Part Three: Adding a New Item to a SharePoint Calendar

Part Four: Create a SharePoint Meeting Workspace

Part Five: Meeting Workspace Integration Investigation Concludes

Happy Halloween from Bamboo and SharePoint Blank!

When we left off in our continuing investigation into the relationship between recurring calendar events and Meeting Workspaces, we were just about to hit Create on the New Item page.  Among the New Item selections I had chosen to apply to my new calendar item was to tick the Workspace checkbox, allowing me to associate a Meeting Workspace with the new calendar event.  As a result, upon clicking the Create button, the next page to render was the New Meeting Workspace page:

As you can see, since I had given my new calendar event the (incredibly unimaginative) name of "Meeting Workspace Test," that's exactly what appeared as the default title for the associated Meeting Workspace.  Note, however, that you're under no obligation to have the title of the Meeting Workspace match exactly the associated calendar event, as the input field is editable, but if you do want to keep the same title, you get it filled in for you automatically.

Moving on, the Description field, as seems to be customary for such fields in SharePoint, is an optional step for you to fill in (or not) as you wish. 

The Web Site Address field allows you to choose the final portion of the dedicated URL for your Meeting Workspace, with the preceding path information prepended for you, as demonstrated in the image above.  To use my example, I'd probably input the URL here as "meetingworkspacetest."

The Permissions field provides you the ability to choose between inheriting the Permissions of the parent site, or manually specifying the levels of permissions available to designated users of the Meeting Workspace by using unique permissions.

Having made my decisions, upon clicking OK, the resulting page is the Template Selection page ... and since my investigation involves the Basic Meeting Workspace settings, it's that (default) template that I'll be selecting:

Clicking OK on the Template Selection page will result in one of two pages.  If you chose to use unique permissions, you'll be presented with the Set Up Groups for this Site page.  If you chose the path of least resistance (use same permissions as parent site) as I did, you'll be presented with your newly minted Meeting Workspace Page, the out of the box "meat" of which should look something like this:

And now, having successfully created a Meeting Workspace page, this is the part where I say, "Tune in next week for the exciting conclusion of our investigation!"

(I know, I'm shameless with these cliffhangers, aren't I?) 

This has been part four of a special collector's item mini-series ... collect all five!

Part One: SharePoint Calendars & Meeting Workspace Integration

Part Two: Create a New SharePoint Calendar

Part Three: Adding a New Item to a SharePoint Calendar

Part Four: Create a SharePoint Meeting Workspace

Part Five: Meeting Workspace Integration Investigation Concludes

Having learned how to create a new SharePoint calendar yesterday, we left off with the realization that we were only part of the way towards answering a related question regarding Meeting Workspaces.  Today, we're going to look at the next phase of my investigation, which involves adding a recurring event to the newly created calendar, and inserting a hook into that event which will associate it with a Meeting Workspace.

The first step in creating the new recurring event is to select the New Item option from the New dropdown menu on the calendar itself:

Once the New Item option has been selected, the resulting page presents standard event scheduling options (that will be familiar to Outlook users), along with the SharePoint-specific Workspace option:

Required fields for the new calendar event are Title, Start Time, and End Time, each of which I trust is self-explanatory. 

The optional Location field is probably equally self-explanatory to you but, well ... get ready to have a laugh on me, my friends, ‘cause it's time for Embarrassing True Confessions.  So, I was puzzling over the meaning of the Location field and, having for some strange reason wrapped myself around the axle of thinking Location might pertain to location within a Site Collection, I attempted to ferret out a definitive answer via some creative Googling.  After a few fruitless minutes communing with Google, I ended up asking a colleague who happened to stop by while I was chewing over this seeming imponderable and ... well, let's just say that he exercised great restraint in not making me feel like any more of an ass for having asked the question in the first place.  Location, of course, pertains to the physical location of the meeting/event that you're scheduling.  Duh.

Thankfully, I didn't have any trouble with the remaining optional fields.  Description is where you'd enter any additional information pertaining to the event, such as an agenda.  All Day Event is for just that: A one-click designation of an event with no specific start or end time.  Recurrence is where you'd indicate a repeating event, and since the question under investigation requires Recurrence, I ticked that checkbox in creating my event.  Clicking that checkbox refreshes the page, presenting you with your Recurrence options:

The final optional decision in creating a new calendar event is the Workspace option.  Since the crux of my investigation hinges on Meeting Workspaces, I ticked this checkbox as well.  A Meeting Workspace, we're helpfully told here, will allow users to "organize attendees, agendas, documents, minutes, and other details for this event."

And that's going to wrap up today's portion of our ongoing investigation.  Tune in tomorrow to find out what happens when I click the Create button on this New Item page. 

Don't you just love cliffhangers?

This has been part three of a special collector's item mini-series ... collect all five!

Part One: SharePoint Calendars & Meeting Workspace Integration

Part Two: Create a New SharePoint Calendar

Part Three: Adding a New Item to a SharePoint Calendar

Part Four: Create a SharePoint Meeting Workspace

Part Five: Meeting Workspace Integration Investigation Concludes

As I mentioned yesterday, an investigation into a forum question regarding integration between a SharePoint Calendar and Meeting Workspace led to several new-to-me SharePoint activities.  While going about the business of my investigation, it struck me as somewhat funny that, despite the considerable research I did in while constructing our Calendaring with SharePoint topic area, I realized that I hadn't ever actually created a calendar in SharePoint. 

Sure, I've been working with SharePoint calendars since my earliest days on the job here at Bamboo but, until yesterday, my experience had been purely in the area of adding-and-editing events to already existing calendars.  I'm happy to report that such is no longer the case, as I created my first SharePoint calendar yesterday.  Which, it should be noted, is hardly an accomplishment to shout proudly from the rooftops because, well, it only takes a few clicks to create a calendar in SharePoint.  That said, however, it was the necessary first step in my investigation since the question I was looking into involved the integration (or lack thereof) between calendars and Meeting Workspaces.

And so, since it was the first phase of my investigation proper, I'll now demonstrate how to easy it is to create a SharePoint calendar in just a few simple steps. 

First, while in the site where you want to create your calendar (and, ultimately, your Meeting Workspace), select the Create option from the Site Actions dropdown menu.  Then, on the resulting Create page, select the Calendar hyperlink under the Tracking heading:

After clicking that Calendar hyperlink, you may be surprised to discover that there isn't anything calendar-centric on the resulting New page:

This lack of calendar-related verbiage may strike you as odd, but there is method to the seeming madness:  You're not really creating a calendar ... you're creating a SharePoint list.  Say what?  Yup, the truth of the matter is that a SharePoint calendar is really just a regular ol' SharePoint list in which the list contents are displayed in a more visually appealing calendar-based view.

As you can see in the above image, all that's necessary to create your calendar is to give it a Name and (optional) Description, decide whether or not to include it in your Quick Launch Navigation, and determine if you'd like to allow users to add items to the list/calendar by sending email (and, if yes, assigning the calendar an email address here).  Once you've sailed through that process, click the Create button and your browser will automatically refresh with the calendar view of your new list.

Needless to say, that default calendar view is going to be empty of content since there aren't any items in the list yet.  Tune in tomorrow for the next installment of my investigation, where we'll create a recurring calendar event, during which act we'll encounter the first onscreen mention of our ultimate goal:  the elusive Meeting Workspace. 

This has been part two of a special collector's item mini-series ... collect all five!

Part One: SharePoint Calendars & Meeting Workspace Integration

Part Two: Create a New SharePoint Calendar

Part Three: Adding a New Item to a SharePoint Calendar

Part Four: Create a SharePoint Meeting Workspace

Part Five: Meeting Workspace Integration Investigation Concludes

The decision as to which of the SharePoint site templates I would investigate next was taken out of my hands due to Bamboo Nation Community Manager Chris Dooley's bringing to my attention a calendaring question that had been posed in our forums.  I suspect that Dooley asked me to take a look at the question for two reasons:  1) I did a fair amount of research in preparation for launching our topic area on Calendaring with SharePoint, and 2) We sit next to each other, so I was the closest colleague he could reach out to who might possibly know the answer.

Well, the question had to do not only with calendaring but with a related SharePoint feature, the Meeting Workspace.  Since I haven't yet had the pleasure of making the acquaintance of a Meeting Workspace in my continuing SharePoint education, I hadn't a clue as to what the answer to the question was.  Nonetheless, I was up for a putting on my sleuthing cap again and mounting an investigation. 

The question itself, posted by Brinton in the Calendaring forum, was:

We're having a heck of a time trying to set up a Meeting Workspace for our regular weekly status update meetings for our project team. In particular the default template for a Meeting Workspace does not appear to handle attendance and agenda changes for regular, recurring meetings. Any suggestions on where to look for solutions? Has anyone out there worked with this and can offer any insight?

Since I plan to spend the next couple of days walking through my investigative process (in which, yes, I performed a couple of new-to-me SharePoint tricks that I will share in detail), however, I'm going to go ahead and reveal the dumbed down version of the answer now.  And that answer is, "yes, but ... well, it's complicated."

Why the dumbed down non-answer of an answer, you ask?  Well, because the full details of the answer involve the integration of multiple Web Parts, and an aspect of SharePoint lists that I've yet to explore.  Which is why the mighty Jeff Kozloff will be posting the real answer to the question in the forum, and I'll just be addressing in SharePoint Blank what I learned while attempting to ferret out an answer.

Stay tuned for the blow-by-blow details of my creation of a SharePoint calendar, my creation of a recurring meeting in that calendar, and my creation of -and interaction with- a Meeting Workspace.  That's a lot of firsts for one day, hence the commemorative multi-part series.

This has been part one of a special collector's item mini-series ... collect all five!

Part One: SharePoint Calendars & Meeting Workspace Integration

Part Two: Create a New SharePoint Calendar

Part Three: Adding a New Item to a SharePoint Calendar

Part Four: Create a SharePoint Meeting Workspace

Part Five: Meeting Workspace Integration Investigation Concludes

As noted last week while investigating how to create a wiki site, I discovered that there are many other, additional template types available that allow you to quickly and easily create a site for collaboration in SharePoint.  Today I'd like to take a closer look at one of those additional templates, the Document Workspace template.

As mentioned previously, the initial decision points are identical for creating all of the collaboration templates, so I won't provide an(other) illustrated blow-by-blow on that process here, but I'm going to create a site named 2009 Editorial Planning for my demo, and I will be pointing out one of the key choices I made differently while creating my Document Workspace, as opposed to my demo wiki site.

Having provided a Title (2009 Editorial Planning) in my setup process, I provided that same Web site Address (/2009EditorialPlanning) in the provided input field, then selected the Document Workspace option under the Collaboration template tab.  It's at this point that I diverged from my wiki creation decision path in order to gain some new insight into the template creation process, and I did this by choosing to Use unique permissions rather than inheriting the same permissions as the parent site:

For my Navigation options, I opted to display my new site in the Quick Launch bar of the parent site, but not in the top link bar, and I chose to use the top link bar from the parent site.  At this point, I was ready to hit the almighty Create button, and so I intoned, "let there be Document Workspace!" and made it so.

Given my earlier decision to use unique permissions, it didn't come as a surprise that I was next presented with an additional step in the site creation process, which was the Set Up Groups for this Site page.   I went ahead and filled out this page by clicking the Add all authenticated users hyperlink for the Visitors to this Site option and, noting that as creator, I had already been auto-added in the Members of this Site and the Owners of this Site fields, I added my team members to the Members field (which uses the familiar Outlook people picker):

(Pop quiz:  Which previously mentioned SharePoint best practice did I just violate in the steps above?  First person to answer correctly wins a signed copy of Dux Raymond Sy's SharePoint for Project Management.)

Upon hitting the OK button on the Set Up Groups for this Site page, presto, I had successfully created my first Document Workspace:

As you can see, the (fully editable) "out of the box" Document Workspace site comes with an Announcements section, a Shared Documents library, a Tasks feature, and modules for Members and Links.  And how long did it take me to create this site, from soup to nuts?  Oh, maybe three minutes from start to finish.  Pretty handy, eh?