October 2004 - Posts

George W. blocks the world
31 October 04 07:32 PM | madsn | 15 comment(s)

Did you know that George W. Bush actually blocks access to his homepage http://www.georgewbush.com for a lot of european and asian based web users? Well he does, according to the danish ComputerWorld webusers from Norway, Great Britain, Austria and Taipei is effectively blocked and receives a 403 Forbidden error. Dubya seemingly uses Akamai technology for this less-open-information-approach.

Well, I can read it anyways through this link:

http://proxy.guardster.com/cgi-bin/nph-proxy.cgi/010100A/687474702f7777772e67656f72676577627573682e636f6d2f

Way to go W! Wonder how you would describe muslim homepages doing the same thing? Hopefully noone will bother reading your homepage when Kerry takes your job in a couple of days.

Filed under: General Opinions/Comments

Workaround for Document Library Change Request #4
28 October 04 07:04 PM | madsn | 5 comment(s)

I think I've might found a workaround for my 4th issue. The problem was that customers wanted to store several attachements in a mail into a Document Library located on a WSS site. Of course, the solution was right in front of my nose the whole time.

We're already integrating with Exchange through Outlook Web Access by simply displaying a public folder dedicated to the site (which in turn is dedicated to a case or project) in a Page Viewer Webpart.

Then it struck me. Why don't we just create a new document library on the site and mail-enable it? When you've got files related to the site (case or project) attached to a mail, you usually want to store the mail aswell, so you just click "Move to folder", and (with the public folder as a favorite in Outlook) it pops right up. Then Sharepoint detects the mail after a while and extracts the attachements into the "Email Attachements" Document Library on the site.

This still doesn't solve the ad-hoc need to store attachements any document library on any site, but it can be used to solve the cases where users most often wants to stuff an attachement into Sharepoint.

Filed under: Office System

How about making WSS Search available in Microsoft Office 2003?
28 October 04 09:55 AM | madsn | 2 comment(s)

Mike commented on my last post and said

"I didn't read Patrick's article because he made it clear that it was for SPS 2003 only (and not for WSS).
So thanks for pointing out this feature from it. Maybe SPS 2003 has its points after all ..."

In my opinion SPS 2003 really have several good points, but that's a discussion for another time. The point here is that organisations that just want WSS and thus cannot hook up to the Microsoft.SharePoint.Portal.Search.WebQueryService through http://server_name/_vti_bin/search.asmx can achieve this aswell in the wonderful world of WebServices:

You simply need to develop a web service interface based on the same contract for the SPS2003 search service (search.asmx?wsdl) and implement WSS search making use of the SPWeb Search methods (or even straight to the database or indexing service). If this service is deployed to sharepoint as described on MSDN it will support site virtualization and you can basically add any toplevel website as a Research topic in Office 2003.

I don't have the time to do this, but if you do: let me know:-)

Filed under: Office System

Make Sharepoint Search available directly in Office 2003
27 October 04 11:56 AM | madsn | 1 comment(s)

Every day I find another little productivity enhancement through correct use of Sharepoint. There are a lot of little known integration points between Office 2003 Desktop applications and Sharepoint, and there are also a lot of well-known whoes and problems in the same sphere. I've focused on the problems a lot lately so I'd like to point out a very cool thing.

Patrick Tisseghem wrote a very good article over at the Office Developer Center on SPS Search. The coolest thing for end users in his article was how to hook in search in the Research pane of Office 2003.

It is very simple:

1. Open Word or Excel
2. Click the header of the toolpane to the right in the window and choose Research
3. Click Research options... in the bottom of the pane
4. Click Add services
5. Enter the following url, replacing "myPortal" with the base url of your portal:
   http://myPortal/_vti_bin/search.asmx
6. Click ok and you've got your portal as a possible source to research from Office!

Way to go Patrick!

Filed under: Office System

Make Messenger presence information availible in WSS
26 October 04 10:42 AM | madsn | with no comments

When deploying corporate intranets with Sharepoint Portal Server all user information is replicated through profiles from Active Directory. For organisations without Live Communications Server, only users with Microsoft Passport accounts that match their Active Directory email will have presence information availible in Sharepoint.

In our organisation several employees switched passport accounts to enable Messenger presence in Sharepoint and Office. Some are still reluctant to give up their personal passport account, and maintaining two accounts with passport is cumbersome.

One solution that works well with Windows Sharepoint Services is to change the user email in team sites you use frequently. Each top-level site website maintains a separate set of emails, and by changing the email presence information will appear through the Microsoft Windows Messenger Service. Note that emails sent from this site will be sent to the passport address aswell.

 

Filed under: Office System

Sharepoint Document Library Change Request #4
21 October 04 05:12 PM | madsn | 2 comment(s)

Oh my god I keep getting deja vu when this scenario occurs with customers again and agan. Need to find workaround quick!

Realizing that beeing able to access document libraries from Outlook (or File Open in general) is actually related to working with doclibs (dooh..) I felt the need to add it to my posts of change requests. You never know; someone might be reading this:-)

Filed under: Office System

Sharepoint Document Library Change Request #3
20 October 04 10:56 AM | madsn | 2 comment(s)

We are progressing on effective document management with Sharepoint with our customers, and we're gaining more and more opportunitites using Sharepoint as a DMS-killer (heavyweight document management system killer). Customers want's a simpler cheaper solution and love the office integration and ease of use. Some features are missing though, and it creates a certain degree of mistrust with customers. True enough, these things are not supported when using file shares either, but I'd like to see them in sharepoint.

Todays requests (and valuable warnings on how it works today):

• Force checkout. Document libraries should be able to enforce checkouts (configurable) to make sure concurrency problems are omitted.
• Warn users when uploaded files overwrite. If you upload a file with the same name as an existing file in the document library Sharepoint will overwrite it. No questions asked.
• Read-only should be read-only. When simply clicking the link to a file in the document library (and not choosing "Edit in Microsoft Word") the file is opened in readonly mode. This is only displayed in the title bar, and when users press ctrl-s the Save As.. dialog appears. If the user assigns the same file name as the existing one and saves, no warnings are prompted.

Until this is implemented it is vital to make this clear to customers early, to set expectations. A roadmap for Sharepoint updates and patches with these features included would be much appreciated!

Filed under: Office System

Common error using the Exception Management Application Block
19 October 04 05:02 PM | madsn | 3 comment(s)

I make extensive use of the Exception Management Application block from Microsoft PAG. A common error I usually get when starting up a new project is that I haven't configured the eventlog on the Windows 2003 Server to allow writing to the eventlog for all authenticated users. The error message is:

"Cannot open log for source {0}. You may not have write access.".

The solution is to locate the CustomSD key (HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/EventLog/Application) in the registry on the server and add the following string to the existing
value:

(A;;0x0002;;;AU)

From this newsgroup post.

Filed under: .NET General

The gap called "included paths"
12 October 04 03:32 PM | madsn | 4 comment(s)

"How do I add two or more documents as an attachement to an email from Outlook" a user asked me.

We're of course talking a pure Sharepoint document management solution, and of course we've locked down every single Z-drive factor (they've got no disks at all) in the network to force all content into the portal.

"Well, uhm..." I responded, whilst scanning my brain, rss feeds, googling, and at the same time opening Outlook to show her how it's done.

"You simply write the url to the portal in the File Open dialog and browse to the files you want to attach, or you can even use that portal link they've made for you in My Places in Office". I was quite pleased with the quick response that actually came from my brain.

"Sounds great!" she replied. "And that will work for document libraries in my project teamsite aswell? You see, I need to send a couple of project documents for QA".

Hammering the File Open dialog in Office with great speed I found no way to navigate to any teamsite on the portalserver. Experimenting with urls in the filename field, however, proved successful. "Oh, well then you have to write http://portal/projects/project123, hit enter and then locate your document library". I lost her on the included path part, on [projectsites].

"Why can't I get a list of those project sites?" The followup was not unexpected. "I'll get back to you on that one.."

Enough storytelling.

There is definately a gap in the navigation of Windows Sharepoint Services sites. The portal areas has a rather nice UI from Office, but there is no way to click into the actual WSS sites. Users expect to be able to get to them through the site directory area.

Why is this important? Weren't supposed to move away from navigating hierarchies? When using network drives and fileshares, experienced users often write complete complex paths like K:\documents\users\me\project123\letters\january\mydoc.doc to find a document, and they memorize it by clicking the path. Comparing this to simply writing http://portal/projects/project123 shows an actual improvement, but the point is that users need to be able to navigate the first few times and then they type the paths directly.

Even better if they could have search capabilities from the File Open (or save) dialogs, but I guess thats further ahead.

Anyone found creative approaches to locating WSS sites in a Sharepoint portal? Users really need to add more than one document as attachements in word at a time.

 

 

Filed under: Office System

Speeding up Sharepoint Immediate Alerts
12 October 04 01:11 PM | madsn | 5 comment(s)

Whenever a user has requested an alert for a list or another object i Sharepoint there is a default delay of 10 minutes. Users are puzzled by not having received an alert when other users tell them that updates have been made to a list or document library.

These settings are not (as far as I know) available from the Central Administration Pages, so the command line is the way to go to speed things up [from Sharepoint University]:

stsadm.exe -o setproperty -pn job-immediate-notification -pv 3

The -pv [PropertyValue] part sets the delay in minutes.

UPDATE: Setting this property seems to make sharepoint push out all alerts ever sent again. When I did this in the production environment every user that had an alert set up for a list got a separate alert for every list item. Fortunately the portal had only been in production for a couple of weeks, so it affected few users, but you should definately investigate this before executing the command!

Filed under: Office System