JT's SharePoint Blog: 2009

Tuesday, December 22, 2009

MySite Profile Hierarchy Does not Display a Direct Report

One of my customers had an interesting issue. Here is the situation:

My customer, Sally, reported to Mr. Smith.
Jan, Stan and Ann also reported to Mr. Smith.
Sally did not show up in Mr. Smith's hierarchy on his MySite profile as reporting to him. However, Jan, Stan and Ann did.
Sally's MySite showed her as reporting to Mr. Smith in her own hierarchy!

It was a puzzle. It was complicated by the fact that the company I work for has multiple ways of pulling data into Active Directory. I first checked out AD, thinking there was a profile error. No dice. Then I checked to make sure the jobs that populated AD did not have issues and was actually pulling and populating the data as designed. Again, not the problem. It turns out I was way overthinking the problem.

The issue is that Mr. Smith had entered Sally's name as his Assistant when he was filling out his profile. When he removed her as his assistant, she displayed properly in the hierarchy.

I assume this is a bug, rather than by design. The assistant property is a manually entered property, even though it is a lookup. This property, when filled out, overrides the hierarchical data pulled from AD. Clever, but when I am looking at the direct reports of a manager, I would not think to gather information from the assistant text box as well. Except now maybe I will...

Tuesday, December 8, 2009

Redirect using a Content Editor Web Part

I am not a web developer, so when someone asked me to create a redirect for a page, I was at a loss. Then someone told me to use a Content Editor Web Part. Wow. It really is that simple.

Add the CEWP to the page. Then click Edit Shared Web Part and click on Source Editor.

Modify the code below to include the site you want to redirect to and add any pertinent text. The HTML below redirects in 5 seconds, but you can shorten or lengthen that by changing the setTimeout.

<HTML>
<HEAD>
<SCRIPT language="JavaScript">

</SCRIPT>
</HEAD>
<body>
<TABLE width=70% align=center cellpadding=10><TBODY bgcolor=#EOEBED><TR><TD><STRONG><FONT size=4 color=#59452A><BR>You will be redirected here: <FONT face=Verdana><A href="http:/yoursite/default.aspx">http://yoursite/default.aspx</A> Please bookmark it for future reference. You will be redirected in 5 seconds or you may click on the link to go there immediately.<BR><BR></FONT></FONT></STRONG></TD></TR></TBODY></TABLE>
</body>
</html>

Friday, November 13, 2009

Overdue Task Notifications being Sent Even Though Workflow was stopped.

A user had started a regular out-of-the-box approval workflow and then decided she did not need the document that the workflow was running on, so she deleted it. A week later, she received an overdue task notification for that document. She figured it just needed time to clear out of the system, so she didn’t say anything to IT. A week went by and she got another notice. She then deleted the entire library – and still the emails kept coming. It was puzzling – the workflow was stopped, yet overdue email notifications were still being sent to workflow participants.

She called me after moving her documents and deleting the site, and still the workflow task notifications kept coming. I was puzzled. After numerous hours spent Googling and frantically trying to eke out an answer on the internet, I remembered something I should have thought of.

We had performed a restore for that site collection a month before (probably why I did not remember it – I can barely remember what I had for breakfast by noon). The restore was placed in a live environment that we use for troubleshooting user issues.

I browsed to the site and sure enough, there was the document, document library and a workflow labeled “In Progress.” Because it was not in a dev environment, it was running SMTP in our production environment and was hosting the workflow as if it existed in the original location.

After I discovered this, I found a couple more instances from other users that had this issue. So apparently, I am not alone. Good thing too – in SharePointLand, alone can be scary!

Monday, November 9, 2009

To wiki or not to wiki? How to deploy a wiki.

If you are thinking about starting a wiki and don't know where to begin, the website that I recommend above all others is wikipatterns.com and was a huge help in deployment and management when I deployed a wiki at my last company. We took a lot of ideas from there. They also have a book by the same name with some case studies that all of our deployment team purchased and read as part of the planning.

We were concerned about several things, mainly the two biggest barriers to wikis: 1) How do we get started, and 2) if everyone is responsible, then no one is responsible. We used the "barn-raising" technique to get the ball rolling. We started with a "Panel of Experts." After they planned and created the basic premise and taxonomy of the site, The Panel of Experts along with all of our business heads and content managers got together for a three-day session to deploy the content. There were about 20 people in all and We made it really fun - had lunch brought in and contests for the people who were entering content, like who could find the most spelling errors during proofreading, and who could wear the goofiest hat. Sounds corny, I know - but it really worked to create enthusiasm around the concept.

The maintenance plan was a was a little harder to decide on. We didn't want to restrict changes to the content too much, because then people would not take ownership or it, but we didn't want to make it a free-for-all either. We settled on a panel of content managers that would set alerts on certain areas of content and when changes were made, they would review them for accuracy on a daily basis. We originally thought that it would be better to have administrators be the only users who could publish changes, but thought that there was probably a good chance of them forgetting to publish the content and then the changes would never happen. We decided that the few people who made incorrect changes were an acceptable risk in order to have all people with buy-in be able to contribute and see their changes in real time. We also made it public knowledge that there was no such thing as "anonymous" in SharePoint, which probably prevented a number of incorrect or inappropriate postings. However, the idea of having all users be able to make edits or create new pages and then have someone else be able to review and publish those changes to a live site is a very viable way to handle this issue and fully supported with out-of-the box Sharepoint.

Friday, November 6, 2009

Weird SharePoint Datasheet View Error with Person Column

Issue: One of my users had a list that had about several hundred items and about 25 columns. She created some views for these items and one was a datasheet view with only about 5 columns. She had created it as a way to modify these columns quickly. However, when she would use this view she noticed something odd: the datasheet view would show duplicates of some of her list items.

When viewing the list in standard view, there was only one of each list item. When we changed to the datasheet view she had created, it would show some items multiple times.

Cause: When we investigated, we found that some of her columns were columns with the data type set to Person or Group. The number of people chosen for the list item directly correlated to the number of items that displayed in the datasheet view! However, when we added the person column to the datasheet view, the problem went away! She really didn’t want that column showing, so we had to figure out what was causing it. We examined her settings on the columns:

• It was a column with a type of Person or Group

• It was required

• It allowed multiple selections

We removed the required field for that column, and the duplicates disappeared! We removed the ability for multiple selections and the duplicates disappeared this way as well.

It was only that combination of having a required person column allowing multiple entries that was not showing in the datasheet view that was causing the problem.

Fix: Unfortunately for our user, her options were to either display the column in datasheet view, disallow multiple entries for the person column or make it a non-required field.

Thursday, October 29, 2009

Site Themes vs. Publishing Infrastructure = Publishing Wins!!

Issue: After enabling publishing on a team site, user is no longer able to change site themes.

Cause: When publishing is turned on, the subsite inherits the master page from the top level site. This overrides the theme. The subsite is set to inherit. The subsite is stuck with the master page and the theme is rendered unchangeable.

Solution:

Open site in SharePoint Designer and open the Catalogues > Master page section in the folder list.
Right click on the master page that you want to inherit from the main site (it will probably be default.master)
Select Set as Default Master Page
If you recieve a warning message, click OK
Navigate back to the site and refresh the page
Go to your Site Settings page and choose a new theme. Click OK
Navigate back to your page and refresh.

You should be showing the desired theme.

NOTE: If you have turned off publishing, you will need to turn it back on for the changes to take place. If you have turned it off before step 1 above, you will not get any result after completing step 7.

Publishing Sites and Version History

One of the users at the company where I work accidently published a version of her page that she actually wanted to hold off on for a week or so. She figured that she would simply revert back to a previously published version of the page and then she could take her time rolling that page out. However, when she reverted back to a previous version, she discovered that the reverted page looked exactly like the new page that she did not want to publish. The reason? Because the changes she made involved deleting and adding web parts to the page and no actual page content changes occured.

Unfortunately, SharePoint publishing page versions do not keep track of new or deleted web parts. If you add or delete web parts, those changes will be pervasive throughout the versions once that page is published.

While there was nothing that could be done about the web parts that were deleted, she chose to close the web parts she had created until she wanted them to display.

Tuesday, October 27, 2009

Site Master vs System Master - Great Blog From Joel Oleson

I was asked by a colleague the other day what the difference was between the System Master and Site Master page. Not being an expert in Sharepoint Design, I really couldn't answer her. Today, while searching for something else entirely, I came across a blog by Joel Oleson that explained this very well.

http://blogs.msdn.com/joelo/archive/2007/04/12/master-page-and-themes-on-wss-sites-in-moss.aspx

Hope you enjoy!

Thursday, October 22, 2009

Changing the .DOC template in your Document Library

When you create a document library, if you accept all the defaults at the time of creation, you will be stuck with a template.doc format. This means that whenever a user clicks on the "New" button to create a document in the library, they will get a Word 2003 template. This is fine if most of your audience for your library is still on Windows 2003. However, if most of your organization is using Windows 2007, you may want the .docx format to be the default.

If that is the case, you can do this very easily by going to Settings à Document Library Settings à Advanced Settings. There will be a section for Document Template. At the end of the URL in that section’s text box (it will look something like “YourDocumentLibrary/Forms/template.doc”), just type an “x” at the end of template.doc. Click Save and navigate back to your library. You will notice the Icon has changed from the old version of Word to the new one.

Tuesday, October 13, 2009

Setting Default view to Monthly in My Outlook Calendar

My company recently updated our Exchange to 2007. Great - right? Well, for the most part, yes. However one thing that we noticed right away is that the functionality for the My Calendar web part changed for our My Sites.

In the past we were able to modify the default view of the My Calendar web part to a daily, weekly or monthly view. However, since the upgrade, we are no longer getting the option for monthly. After searching forever for a solution to this issue, I was stumped And then I read that the new version of Exchange did not support monthly views for OWA. Since OWA runs this web part, it would make sense that it was not displaying. (By the way, SP1 fixes this issue for OWA, but not for the SharePoint web part.)

In any case, we found that when we wanted to switch to a monthly view we still could (there is a handy button on the toolbar for this). However, we could not make this our default view. As you can see from the screen shot, there are only two options, and neither is monthly.So we had to find a workaround.

In the Mail Server Address section, add the name of your mail server address as usual. In the mailbox, use your regular mailbox address (yourname@yourcompany.com, for example and add to it the following string:

/?cmd=contents&part=1&module=calendar&view=monthly#

Once you do this, click OK and you will have your web part once again displaying a default view of monthly.

NOTE - On my site, I had to resize the calendar to get it to display. I left the width alone, but modified the height of the web part to 600 pixels and that seemed to work nicely.