I love RSS. It is the best way to keep up with all of my favorite blogs, like the Scott Adams Blog (Dilbert), Scott Berkun's blog, and of course, Joel Oleson, Asif Rehmani, Shane Young... and the 15 or so most interesting SharePoint blogs out there.
Using the RSS Web Part is great. You can have all of your favorite blogs delivered to your MySite. However, SharePoint does not allow internal SharePoint RSS feeds unless you are using Kerberos authentication. Unfortunately, the company where I work does not currently use Kerberos, so, my internal SharePoint RSS feeds were - up until recently - non-existent.
But there is a workaround - as there is for most challenges in SharePoint. It's called the Smiling Goat Feedreader, which is available on Codeplex here - http://feedreader.codeplex.com/
The good:
It was extremely easy to install and deploy. It is simple for end-users to configure, and it surfaces RSS feeds for lists and libraries very smoothly with almost no cost to page load time. And the name always makes people smile!
The bad:
There is not a lot of documentation out there on this web part, which is one of the main challenges of freeware or shareware in general, and therefore, our security team was initially a bit squeamish about loosing a freeware web part in our production environment. If this is a concern for your security folks, make sure it is fully tested in your lower environments first. (Although, that said, Microsoft does refer to the web part favorably in some of their technet articles.)
Another annoyance is that the designer's initials show on the Web Part Title bar and there is no way to remove them. If you have a fussy site admin, they will not like this.
However, the advantages definitely outweigh the drawbacks. It is nice to finally get internal feeds on important document libraries and lists delivered right to my MySite or my own private pages. Our site admin likes it because always the 10 most recent documents display from the library, so it keeps her site current.
The Kerberos requirement for internal feeds does not change with SharePoint 2010. But don't let that get your goat! Instead, get the Smiling Goat!
Tuesday, June 29, 2010
Wednesday, June 16, 2010
Ready or Not...SharePoint 2010!
Well, I have finally done it! With three virtual machines running variations of the new SharePoint 2010, I am ready to start blogging about the new version. I still love 2007 and will keep posting about it as well. I know some people are not ready to make the leap yet. However, I was lucky enough to earn the position of Technical Editor for the new SharePoint 2010 Inside and Out book that is soon to be published and I have been sandboxing my little heart out trying to make each chapter a reality.
Also I have recently procured the new book by Todd Klindt, Shane Young and Steve Caravajal called "SharePoint 2010 Administration" and cannot WAIT to dig in! BTW, Shane Young is one of my very favorites and I have had the pleasure of teaching in his footsteps at SharePoint Solutions. I will keep you posted on the book and any new SharePoint 2010 tidbits I pick up along the way!
Also I have recently procured the new book by Todd Klindt, Shane Young and Steve Caravajal called "SharePoint 2010 Administration" and cannot WAIT to dig in! BTW, Shane Young is one of my very favorites and I have had the pleasure of teaching in his footsteps at SharePoint Solutions. I will keep you posted on the book and any new SharePoint 2010 tidbits I pick up along the way!
Tuesday, June 15, 2010
Moving a List with Large Attachments
I was asked the other day for assistance with moving a list that had attachments. My first thought was that I would just save the list as a template and recreate it in the site the user needed it in. However, that was a quick judgement based on my initial assumption that the attachments were of a manageable size. They were not - they were huge, and it made the list too large to save as a template. Publishing was not enabled, so I could not move the list using Manage Content and Structure. I figured I was in for a long night whereby I would have to save off each attachment and then reattach them once the list items were actually moved.
As a last ditch effort to save time (and my precious evenings with my most important SharePoint student) I tried to see if I could accomplish this in SharePoint Designer. As I played around with the list, I noticed that the attachments were saved in a folder called Attachments....
...and in sub-folders from there where the title of the folder that matched the ID of the list item. AHA!
So, I exported the list to Excel to preserve the content. I also exposed the ID column to capture that information on the old list. On the destination site, I created a new list in SharePoint by importing the exported spreadsheet. (Take care when you do this that the column you want to link to the edit menu is the left most column before it is imported.)
Once you have your new list, open it up in SharePoint Designer. Again, you will have to match the IDs of the old list items with the new, since they might not match. Create new folders under the Attachments folder and name them according to your new attachments folder, then map the new folders to the old. So, from the old list, ID #15 might have an attachment, but you will need to ensure that the old #15 is the new #15 also.
After you create the new folders, simply copy and paste the items from each folder. (Note that it will not allow you to simply copy and paste the folders themselves, only the content.)
It worked great and my user was able to use her new list the very next day - without my having to spend the night at work!
As a last ditch effort to save time (and my precious evenings with my most important SharePoint student) I tried to see if I could accomplish this in SharePoint Designer. As I played around with the list, I noticed that the attachments were saved in a folder called Attachments....
 |
| General Attachments folder at the root of the list. |
...and in sub-folders from there where the title of the folder that matched the ID of the list item. AHA!
 |
| Folders under the Attachment folder. Note the folder name is the Item ID No. |
Because while I could not move the list item itself, I could move the folder contents!
Once you have your new list, open it up in SharePoint Designer. Again, you will have to match the IDs of the old list items with the new, since they might not match. Create new folders under the Attachments folder and name them according to your new attachments folder, then map the new folders to the old. So, from the old list, ID #15 might have an attachment, but you will need to ensure that the old #15 is the new #15 also.
After you create the new folders, simply copy and paste the items from each folder. (Note that it will not allow you to simply copy and paste the folders themselves, only the content.)
It worked great and my user was able to use her new list the very next day - without my having to spend the night at work!
Tuesday, June 8, 2010
ForeFront Error for Excel - Large Uncompressed File
We have begun to use SSRS in our environment. I am huge fan of what it can do, even though I don't know that much about it. One thing that it did allow our users to do is to download raw data. This is great, because now they have access to it. However, an issue recently arose when a user wanted to share that data on SharePoint with Forefront installed.
Recently, a user exported raw data from the SSRS into an Excel 2007 spreadsheet. He wanted to share that data with his team, so tried to upload it to a SharePoint library. It failed with the following error: Virus Name - "Large Uncompressed Size".
The file was not too large - only 33 MG. (Ok, that does sound large. But our upload limit is 150 MG, so it should not have had a problem.) During troubleshooting, I converted the file to a 2003 Excel file and it inflated the size to 88 MG, but it uploaded fine. It also uploaded fine in comma delimited text format. Additionally, I cut out half the data (down to 22,000 rows) and it uploaded okay. Just for fun, I created another worksheet in the same workbook and pasted the 23,000 rows I had cut from the first worksheet. It also uploaded just fine. Therefore, the problem was not the data and of course there was no actual virus.
Although we did not realize it until we had spent days testing, part of the issue actually had to do with the amount of rows and columns that the spreadsheet contained in a single worksheet - 45,000 rows and 250+ columns. The other part had do do with the XML structure of Excel 2007 documents. Forefront was actually timing out when it tried to read all of that XML data in one chunk. This is why dividing it up the data into smaller chunks allowed the document to upload successfully.
When we contacted Microsoft for problem resolution, they suggested that we turn off scanning for all Excel files. We informed them (very nicely) that this was against our security protocol. After a few days, they came back with a fix that involved adding two registry keys specific to Excel files that would increase the timeout limit on scanned Excel documents.
I have good and bad news. The good news is that this worked. The bad news is that due to Microsoft legalities with my company, I was not allowed to publish the registry keys that needed to be added. Apparently, this is "super confidential" and my network administrator did not feel comfortable letting me in on the secret. That said, I wanted to post this anyway in order to give anyone out there the comfort that there is actually a fix for this annoying problem.
By the way, there are a few Microsoft KB Articles out there that reference altering registry keys for a similar issues. Keep in mind these do not work for this particular Excel issue, but it is worth noting here:
http://support.microsoft.com/kb/972074 -Refers to the errors you recieve when you upload a document that contains smaller files that exceed the Forefront upload limit. It also mentions how to skip the scanning of these documents.
http://support.microsoft.com/kb/972072/ - Walks you through the process of eliminating large uncompressed files from the ForeFront scan.
Recently, a user exported raw data from the SSRS into an Excel 2007 spreadsheet. He wanted to share that data with his team, so tried to upload it to a SharePoint library. It failed with the following error: Virus Name - "Large Uncompressed Size".
The file was not too large - only 33 MG. (Ok, that does sound large. But our upload limit is 150 MG, so it should not have had a problem.) During troubleshooting, I converted the file to a 2003 Excel file and it inflated the size to 88 MG, but it uploaded fine. It also uploaded fine in comma delimited text format. Additionally, I cut out half the data (down to 22,000 rows) and it uploaded okay. Just for fun, I created another worksheet in the same workbook and pasted the 23,000 rows I had cut from the first worksheet. It also uploaded just fine. Therefore, the problem was not the data and of course there was no actual virus.
Although we did not realize it until we had spent days testing, part of the issue actually had to do with the amount of rows and columns that the spreadsheet contained in a single worksheet - 45,000 rows and 250+ columns. The other part had do do with the XML structure of Excel 2007 documents. Forefront was actually timing out when it tried to read all of that XML data in one chunk. This is why dividing it up the data into smaller chunks allowed the document to upload successfully.
When we contacted Microsoft for problem resolution, they suggested that we turn off scanning for all Excel files. We informed them (very nicely) that this was against our security protocol. After a few days, they came back with a fix that involved adding two registry keys specific to Excel files that would increase the timeout limit on scanned Excel documents.
I have good and bad news. The good news is that this worked. The bad news is that due to Microsoft legalities with my company, I was not allowed to publish the registry keys that needed to be added. Apparently, this is "super confidential" and my network administrator did not feel comfortable letting me in on the secret. That said, I wanted to post this anyway in order to give anyone out there the comfort that there is actually a fix for this annoying problem.
By the way, there are a few Microsoft KB Articles out there that reference altering registry keys for a similar issues. Keep in mind these do not work for this particular Excel issue, but it is worth noting here:
http://support.microsoft.com/kb/972074 -Refers to the errors you recieve when you upload a document that contains smaller files that exceed the Forefront upload limit. It also mentions how to skip the scanning of these documents.
http://support.microsoft.com/kb/972072/ - Walks you through the process of eliminating large uncompressed files from the ForeFront scan.
Monday, June 7, 2010
Replacing the Default Permissions Email Text
For the longest time, our users had expressed their annoyance with the out of the box email template that is received when permission to a site is granted. Typically, the text give you a welcome message and then proceeds to detail out "What is a SharePoint site?" If your users are like ours and already are well-acquainted with what a SharePoint site is, it might be time to change that message.
Although it is recommended not to change any default files, doing this is reletively harmless if, of course, it is tested thoroughly and done with caution. The file itself is an XML and is located in the 12 Hive (c:\Program Files\Common Files\Microsoft Shared\web server extensions\12) in the Resouces folder. The file is called core.en-us.resx.
To edit this file, you will need to open it up in Notepad and press CTL + F to search for the text "What is a SharePoint Site?" Once you find it, you will want to replace everything from "What is a SharePoint site?" to "...members of the site can contribute their own ideas and content as well as comment on or contribute to other people's." with the XML character for a non-breaking space (@#160). This will keep all of the tags in place and you will recieve emails without any text below the name of the site and the type of permission you were given.
Additionally, you will need to revise your documentation for installing service packs to include backing up this file before the Service Pack install and reapplying it afterwards, since it will most likely be overwritten when Service Packs are installed. However, when I recently installed the February Cumulative Update in my 2007 environment, and it did not affect this file.
Although it is recommended not to change any default files, doing this is reletively harmless if, of course, it is tested thoroughly and done with caution. The file itself is an XML and is located in the 12 Hive (c:\Program Files\Common Files\Microsoft Shared\web server extensions\12) in the Resouces folder. The file is called core.en-us.resx.
To edit this file, you will need to open it up in Notepad and press CTL + F to search for the text "What is a SharePoint Site?" Once you find it, you will want to replace everything from "What is a SharePoint site?" to "...members of the site can contribute their own ideas and content as well as comment on or contribute to other people's." with the XML character for a non-breaking space (@#160). This will keep all of the tags in place and you will recieve emails without any text below the name of the site and the type of permission you were given.
Additionally, you will need to revise your documentation for installing service packs to include backing up this file before the Service Pack install and reapplying it afterwards, since it will most likely be overwritten when Service Packs are installed. However, when I recently installed the February Cumulative Update in my 2007 environment, and it did not affect this file.
Subscribe to:
Posts (Atom)