Mauro Cardarelli

Attachment Size Limit Question

Mauro — Thu, 25 Sep 2008 11:06:00 GMT

Got this question a few days back and thought I would share the answer (as I have seen it posed a few times)...

We have emailed enabled a discussion board and it works fine except for emails with attachments greater than 2 MB in size.

We are using the default for document libraries at 50MB (and we dont have an Exchange limit)...the email just gets rejected.

Is there a size limit on attachments? If so, can we change it?

The answer is that this is not a SharePoint problem; it is an SMTP server limitation. To resolve this, do the following:

Launch IIS Manager and navigate to the SMTP server
Go to the properties of that server
On the Messages tab, look for the size limit for attachments (typically it is 2MB)
Change this value to a more acceptable limit and click Apply

SharePoint Users and Administrators Needed for Microsoft User Research

Mauro — Tue, 09 Sep 2008 10:19:00 GMT

I recently received an email from a friend (Karen Angelli, a UX Designer for Microsoft Office). She mentioned that they are working to improve the user experience of SharePoint for the next release, which has some very interesting changes to the UI. They will do remote usability studies for this release, but they need help in finding good participants!

Here’s the blurb:

SharePoint Users and Administrators Needed for Microsoft User Research.

Microsoft User Research conducts thousands of usability studies, focus groups, and site visits every year with real end users just like you. We do this for every single product we make but at the moment we are particularly interested in people who use SharePoint. Whether you’re a hard-core SharePoint administrator or an occasional end user, we would like to talk to you about your experience with the product.

You may get to experience a new product or new feature of an existing product that has not been released to the public. We’ll ask you for honest feedback about your experience in order to make improvements to the final product before we ship it. Your feedback can make a real difference in the user experience for millions of future users! As a thank you for your participation, we’ll offer you a choice of retail Microsoft products from a list of our most popular titles including Office 2007, Windows Vista, Xbox 360 games, Zune accessories, and much more.

Interested? Sign up online at www.microsoft.com/UserResearch. We’ll contact you directly when we have a study that matches your experience and interests.

Installing a Language Pack for MOSS

Mauro — Tue, 12 Aug 2008 09:56:00 GMT

The multi-lingual capabilities in MOSS are very cool. You can create sites in non-English languages simply by installing the appropriate language pack. This is especially slick when you are using variations (will cover this in another post). Note, the installation process is not very intuitive so I’ll provide details below.

1. Download the appropriate files.

a. For MOSS, you will need the MOSS and WSS files

b. Remember there are specific 64bit versions

c. On each of the download pages, change the language in the selector to the language pack you want

d. Here are your download links

i. WSS Language pack http://www.microsoft.com/downloads/details.aspx?FamilyId=36EE1BF0-652C-4E38-B247-F29B3EEFA048&displaylang=en

ii. WSS Language pack SP1 http://www.microsoft.com/downloads/details.aspx?familyid=EF93E453-75F1-45DF-8C6F-4565E8549C2A&displaylang=en

iii. MOSS Language pack http://www.microsoft.com/downloads/details.aspx?FamilyId=2447426B-8689-4768-BFF0-CBB511599A45&displaylang=en

iv. MOSS Language pack SP1 http://www.microsoft.com/downloads/details.aspx?familyid=1F5C7D10-B4F9-482D-B0E5-9547A7F508E5&displaylang=en

2. Install the files

a. The install wizard will be in the language of the language pack… so know how to say ‘Next’ in that language!... or practice on the English version

b. Follow these steps

i. Install WSS Language Pack (don’t run the MOSS Configuration Wizard)

ii. Install MOSS Language Pack (don’t run the MOSS Configuration Wizard)

iii. Install WSS Language Pack SP1 (don’t run the MOSS Configuration Wizard)

iv. Install MOSS Language Pack SP1

v. Run the MOSS Configuration Wizard (choose to not disconnect from farm)

3. Test

a. Create a new site; you should see a drop down for Language which includes your newly installed language

b. Go to the new site and learn how to say ‘Site Actions, ‘Edit Page’ in a foreign language!

Troubleshooting Web Parts in a Restored Portal Environment

Mauro — Sun, 10 Aug 2008 10:45:00 GMT

I have always felt that one of the greatest features in SharePoint, going back to the 2003 version, was the ease at which you could restore a copy of your environment. Having that backup file can prove to be very powerful in setting a development copy of your portal or even restoring in the event of a real disaster. A key piece of this process is to understand what is NOT carried over in a backup. First, custom web part files (i.e. dll's) which typically reside in the /bin folder of your portal directory will not come over. You will need to copy these manually or re-execute a deployment package. The other important piece to note is that in the restoration process SharePoint resets the web.config to its default state. What does that mean? All registration for custom and third party web parts as safe controls is lost. The challenge with this, of course, is that your restored portal pages maintain their reference to these web parts so, after the restore, certain pages may throw errors or reference web part errors. Once again, here is my plug to have a fully documented Disaster Recovery plan that details all custom or third party web part installations.

All that said, sometimes "stuff" happens and you don't have a document. Maybe you inherited an environment; maybe the SharePoint person is on vacation. Here is a quick primer on troubleshooting web part problems in a restored environment (this is especially useful in the 2003 version [pre-Features] but pertains to 2007 as well)…

1. Note all custom and 3^rd party web parts being used; also determine if you have installation instructions (if not, note the location of the web part files on the file system)

2. Take a copy of the production web.config file

3. Restore your environment

4. Perform all web part deployments. If you don’t have an automated process, copy all appropriate files (typically in the /bin folder or GAC) to the same location on the new server

5. This gets you all the way there 90% of the time. Two things to look for if you have problems after this point…

a. Check the original web.config file for differences against the current version. I have never been a big fan of dump and run (i.e. copying over the original file). Use this opportunity to understand the differences. One of the first places to look is the Trust level. Some web parts will want you to increase this to Full to execute with elevated privileges. You’ll want your systems to match.

b. Look for an appSettings section. This will contain application parameters that a web part might use to connect to another system or access external content. Often times, these parameters will point to the original server database or file system. Make sure all parameters point to the right place.

c. I always do an IISRESET after web.config changes

That’s it! I advise folks to do quarterly restores (at a minimum). More than anything, it helps prove that you can actually do one. And remember, document everything!

If I Only Had 5 Questions...

Mauro — Fri, 01 Aug 2008 11:45:00 GMT

I had an interesting challenge posed to me recently. I was asked to offer design assistance on a new collaboration environment for a collection of virtual teams. The goal was to provide each team with a SharePoint site where they could post content and use native SharePoint tools for collaboration and communication. The challenge was the environment needed to be built very quickly so there was no time for information architecture design sessions. In fact, I couldn’t even talk to anyone to get more details. I was asked “What would you do?”. So, I turned this into a challenge… What five questions would I ask, with no other contact, to influence the design, deployment, support, and governance of this new environment. Here are mine:

1. Site Template – I’m going to demand that every team’s site looks the same. What core web parts will leveraged in the site template (document library, calendar, announcements, etc.)?

2. Security – Can we keep security simple and allow contribution by all members but isolate site administration to IT?

3. Shared Content – Let’s assume that each team has unique content. Is there any information that should be “pushed” to all teams (i.e. announcements, links, etc.)? If yes, then let’s adjust the site taxonomy to allow for a shared parent site where we might pull group content (through CQWP or DVWP).

4. Training – How much time for training can we expect? This will help match effort to medium (cheat sheet, videos, instructor led, etc.).

5. Extension – Beyond the base site and web parts, how will you deal with requests for extended functionality (RSS, wikis, subsites, etc.)? You can (1) Enable [forcing administrator privileges] (2) Allow [forcing IT help desk requests] or (3) Deny [forcing activities to stay within the scope of the template]

I may not get to the optimal design with the answers to the above but I would argue that they would help get to a design that offers much more scalability, supportability, and usability.

What would your five questions be?