Archives

Archives / 2004 / November

Syncronization of Office Document Properties with WSS Document Libraries

Monday, November 22, 2004

No Comments

I've been spending a lot of time with Office and syncronizing properties with WSS document libraries I thought I would share. There are a few sources out there like the WSS FAQ section on Office Interaction but I thought I would try to get into some more detail here as there are some dos and donts and gotchas along the way.

Concept

When you upload a document through one of several ways, properties from the document will transfer to SharePoint fields automagically. This assumes you've actually setup the fields in WSS (only the Title property is created by default). There are four ways to upload a document to a SharePoint document library where this works:
1. Copy and paste the document into Explorer View
2. Drag and drop a document via a mapped drive (Windows XP only) or through your Network Places folder
3. Save the document directly from Word/PPT/Excel into a WSS document library.
4. Upload multiple files via the Office 2003 capability
The last two options require Office 2003 (although you can save from Office 2000 and XP it doesn't always work properly as WebDAV is a little kludgy)

Uploading the document through the "Upload Document" option on the toolbar for the document library is a Upload->Set Properties excercise. In other words, you have to upload the document (by picking it via the Browse button) then set the properties. When you select a file from your system to upload, the properties are not automatically set (although I feel they should be so hopefully we'll see this in a future version or service pack). Using the "Upload Multiple Files" gets around this problem, but again requires an Office 2003 client.

Built-in Properties

Word, Office, Powerpoint and Excel (and maybe OneNote and the other "core" products) have a set of default file properties. You can set these programatically (through COM automation) or via the File | Properties menu. These properties are:
- Subject
- Author
- Manager
- Company
- Category
- Keywords
- Comments
- Hyperlink base
These properties do not transfer to a SharePoint document library (again, I think a failing of WSS and should be fixed).

Note: There is something deep in the central administration screens that talk about mapping Office DAV properties so I'm still looking into how this works and maybe to overcome this problem.

Custom Properties - Microsoft

In addition to the built-in properties, Microsoft creates by default a series of custom properties. These are accessible via the File | Properties menu on the Custom tab. By default they're all blank but you can choose to set any of them. These are named:
- Checked By
- Client
- Date completed
- Department
- Destination
- Disposition
- Division
- Document Number
- Editor
- Forward To
- Group
- Language
- Mailstop
- Matter
- Office
- Owner
- Project
- Publisher
- Purpose
- Received from
- Recorded by
- Recorded date
- Reference
- Source
- Status
- Telephone number
- Typist
Creating a field in the WSS document library with the same name as these will result in a transfer (if the property is set in the document and you use one of the four ways to upload the document). Note that once you create a field, it has an internal name (like Status) but you can change it after the fact. It will always have that internal name and if that name maps to a property, it stays that way no matter what name you change it to.

Custom Properties - Yours

Just like the default custom properties that Microsoft creates, there's no stopping you from adding any custom property. Just type in the name in the File | Properties custom tab and click Add. This will add a new property like "Creator" or something. You'll still have to set this but if you do, it will transfer to WSS (again if you create the field in the document library to match).

Transfering

As mentioned in this blog, properties set in Office documents will transfer to a WSS document library as long as two conditions are met:
1. The property is set in the document itself as a text custom property
2. The field is created in the WSS document library as a text field
Custom Properties - Lookups

One of the nice things about having meta-data for your documents in WSS is that you can control the properties and lookup values. Lookup tables are great for this but there's a problem with properties and transfering using a lookup. It doesn't work. Say you have a field called "Status" (one of the default custom properties) and set it "Draft" in the document. Status is a lookup into another SharePoint list you created where the user can set the value. When you transfer the document to WSS, the property doesn't get set.

However if your "Status" field in WSS is a choice field with the values you want AND you have the document property set to something that matches, the transfer works correctly. WSS doesn't care you have a custom property called "Status" in your document with a value of "Fixed" but the choices in WSS are only "Draft" and "Final". It will gleefully set the value to "Fixed" but when you edit the properties, since WSS can't find "Fixed" in the list of choices, it'll revert back to nothing (or the default value if this is a mandatory field).

So basically, if you want to have a picklist for your lookups and syncronize those values from Office -> WSS and back again:
1. Ensure the WSS field type is "Choice" with a set of values (multi-choice through checkboxes does not syncronize)
2. Ensure the property in Office is a text value and matches one of the choices in the WSS document library
Value Types

Office documents let you create 4 different value types for custom properties. Synchronziation (and the field type) in WSS must be text only and the type in the office document must be the same so store all custom properties in your office documents as Text fields in order to ensure synchronization.

Syncronization

As for keeping things in sync, if you set the property in WSS it will transfer to the document so when you open it and look at the File | Properties | Custom tab they'll be updated. If you set it in the document it will tranfser using one of the four methods described above. If you save a single document directly into the document library, it will clear out the file property and ask you for the value.

Summary

In conclusion, it's a powerful feature to synchronize (and populate) SharePoint document libraries with properties from Office documents. Imagine if you had a document library with all kinds of views using meta-data and you had a massive amount of documents with these properties set. A simple drag-n-drop operation into your document library and now all your views are ready to go. Even with issues around syncronization and non-existent built-in properties, it's a useful feature to leverage in your solutions.

Other References

WSS FAQ - Interaction with Office
WSS FAQ - Syncronization Issues with Certain Properties
Removing Large Document Libraries

Tuesday, November 16, 2004

No Comments

Haven't been blogging much as I've been burning the candle at both ends (and sometimes all three ends) trying to get wrapped up for 2004 and ready for 2005 at work (not an easy task). I did have a tip that I came across though that I thought I would share.

If you have a very large document library or list (either one with a lot of folders/documents or one with very large documents) you may find if you try to go and delete the library/list from the settings page that it fails (with a very cryptic message to contact your server administrator). The easy solution is to jump into Explorer view (yes, I hate it as much as you do) and delete files and folders from there, not grabbing too many at once. Basically I found that deleting 30 or 40 folders/files at once to be a good number. Sure, it can take awhile and you can experiment on increasing that number but I suggest you don't try selecting all 1000 files at once and deleting them. If you don't have Explorer View (personally I delete them on all my document library until Microsoft fixes the version bug with them) then just use your Network Places (or a mapped drive under XP) to get to the site and delete from there. For some reason when you delete the entire library from the admin screen, it sometimes chokes so this is a way around it. Your mileage may vary.
Your very own Quick Launch

Thursday, November 11, 2004

5 Comments

A question that gets asked often is about the Quick Launch menu in WSS sites. Whenever you create a list or document library, one of the options is to show it on the Quick Launch. This places it into a grouped category under Documents, Pictures, Lists, etc. It's very effective for directing your users to the content of the site. There are however sometimes where you want to control what you display here and in some cases, users get confused over seeing a heading called Surveys but none to be found. A simple fix is to load the page up in FrontPage and remove those sections. However here's a tip that makes it more flexible (yes, you'll still need to do this in FrontPage but only once).

The whole Quick Launch area is just a simple table made up of Navigation webbots and headings. Rather than having tables for our Quick Launch let's replace it with a new Web Part Zone. This way we can allow web developers (and/or people with the appropriate rights) to add web parts to this section rather than having them load up FrontPage to do any customization.

The table in question starts at line 118 of default.aspx. You can select it in design mode and either delete it or just clear out the contents (I suggest highlighting the contents and deleting it, leaving an empty table).

So this gobbly-gook:

<TD class="ms-navheader"><A HREF="_layouts/1033/viewlsts.aspx?BaseType=1">
  Documents</A></TD></TR>
    <TR><TD style="height: 6px">
  </TD></TR>
    <TR><TD class="ms-navheader"><A HREF="_layouts/1033/viewlsts.aspx?BaseType=1&ListTemplate=109">
  Pictures</A></TD></TR>
    <TR><TD style="height: 6px">
  </TD></TR>
    <TR><TD class="ms-navheader"><A HREF="_layouts/1033/viewlsts.aspx?BaseType=0">
  Lists</A></TD></TR>
    <TR><TD style="height: 6px">
  </TD></TR>
    <TR><TD class="ms-navheader"><A HREF="_layouts/1033/viewlsts.aspx?BaseType=3">
  Discussions</A></TD></TR>
    <TR><TD style="height: 6px">
  </TD></TR>
    <TR><TD class="ms-navheader"><A HREF="_layouts/1033/viewlsts.aspx?BaseType=4">
  Surveys</A></TD></TR>
    <TR><TD style="height: 6px">
  </TD></TR>
       <TR><TD style="padding-left:0px;padding-right:0px"><img width=1px src='/_layouts/images/blank.gif' ID='100' alt='Icon' border=0></TD>

Becomes this:

<TD class="ms-navheader"> </TD></TR>
    <TR><TD style="height: 6px"> </TD></TR>
    <TR><TD class="ms-navheader"> </TD></TR>
    <TR><TD style="height: 6px"> </TD></TR>
    <TR><TD class="ms-navheader"> </TD></TR>
    <TR><TD style="height: 6px"> </TD></TR>
    <TR><TD class="ms-navheader"> </TD></TR>
    <TR><TD style="height: 6px"> </TD></TR>
    <TR><TD class="ms-navheader"> </TD></TR>
    <TR><TD style="height: 6px"> </TD>

Optionally you can delete all the rows (the <TR> tags) and just have one row. Now place your mouse cursor where the empty table is and select Data | Insert Web Part Zone from the FrontPage menu. This creates a new zone where the menu was:

<WebPartPages:WebPartZone id="{8D0A3551-0BFE-4AEA-B16E-C70539440704}" runat="server" title="Zone 1">
</WebPartPages:WebPartZone>

Double click on the zone in design view and change the name to something meaningful (like "Menu"). Save the page and you're good to go. Now your web designers don't have to fire up FrontPage to change your system and you can drop any web part into that area.

Additional things you can do when you're in FrontPage:
- Set the style of the <TD> tags to ms-bodyareaframe so any web parts you drop in here look like the rest of the page
- Remove the "Quick Launch" image
- Change the style of the surrounding table from ms-navframe to ms-bodyareaframe (or remove the style completely) so it doesn't stand out from the rest of the page.
Now what can you put in this new zone? Plenty.

You could create a custom list to hold menu links, adding columns to the list for visibility (like a checkbox called Published or Visible) then create a view that filters on that. Anytime you want to add a new menu item it's as easy as adding it a new item to the list (or changing a property of a previous one to make it appear in the view).

There are also some great treeview web parts out there (CorasWorks has one that gives you a heirachial tree view of the entire site and there are other freebies that show you an explorer like view of your document libraries). Look around and you'll find some great stuff.

You can also save this site as a template to recreate it easily or even replace the default.aspx page on the server so any new team sites are created with this capability. Lots of possiblities here so use your imagination.

Additional links:

Ian Morrish has a great article on creating a dynamic menu using Web Part Pages that exist in a document library.
Jim Duncan has a blog on how to use a XSLT Data View and grouping to create a custom expand/collapse behavior with lists. Combine this with Ian's menu and you'll have a slick UI that's all data driven from your site.

Have fun!
Access denied to your own ASP.NET application

Thursday, November 4, 2004
General Software Development
4 Comments

Every have a bad day with your ASP.NET app? Ever get the yellow screen of death with this on it:

Access to the path "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\myapp\5607edd7\fc4d1071\hash.web" is denied.

If you go googling for the problem, you'll find a few suggestions, solutions, ideas, and rants. We had the same problem happen at our shop a few times in the same week. In fact, it got to the point where we (the users in the local Administrator group) couldn't even access the folders themselves.

After putting our proverbial minds to work, we did something fairly simple. We reclaimed ownership of the folders. You can do this in the security tab of the ASP.NET Temporary files directory.
1. Right click and select "Properties"
2. Select the "Security" tab
3. Click on the "Advanced" button
4. Select the "Owner" tab
5. Select the owner (MACHINENAME\Administrators), check the "Replace owner on subcontainers and objects" and click OK
Voila. Problem gone. App working again. Everyone is happy.