MOSS 2007 - The Great Hard Disk Consumer

Recently I've been performing a bit of a review on som MOSS servers that are a little "under-specified" on the hard disk front. While you probably shouldn't have anything with as little as 10GB as your only drive on a SharePoint server, it has got me looking at some of the places that SharePoint just eats needless space if you let it.

The Databases

Watch out for the SharePoint_Config database particularly - the log file can grow and grow in "default" SQL configurations. A sensible maintenance plan, or at the very least setting databases to backup in "simple" mode will dramatically reduce the size of the logs you are working with (GB down to about 20MB). You should understand the impact of changing your backup modes before you make any changes though. You have been warned™

IIS Logs from Searching

IIS will by default be generating loads of log file data - particularly when the content crawling is happening. You probably want to keep IIS logs for "normal" use, but not for content crawling. If you create yourself an alternative access mapping you can index all your content of one web application url (eg internal.enterprise.com), and turn off logging in IIS, while users access the other one (eg live.enterprise.com) , with logging switched on.

Diagnostic Logging

SharePoint puts its diagnostic logs in:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS

and by default logs very verbosely. You can change these settings to only log the more "interesting" severities through Central Admin > Operations > Diagnostic Logging

WSS_AdminService.log

You will find a log file called WSS_AdminService.log held in

C:\Documents and Settings\Default User\Local Settings\Temp

The file is being written to almost constantly and becomes very large (900Mb by the time I found it).Worse still, because it's in the

C:\Documents and Settings\Default User

folder it gets duplicated when a new user logs onto the server console. Deleting it resolves the situation temporarily (i didn't notice any errors), but it will appear again and start growing.I'm not sure how to "solve" this one, as it seems completely unknown to the internet aprt from this one link (no solution).

http://www.tek-tips.com/viewthread.cfm?qid=1363719&page=6

If and when I find the answer to this and other similar capacity issues I'll ammend this entry. For the meantime, careful monitoring and deletion should keep things right.

Configuring MySites under your main portal

If, like the rest of the work, you'd prefer people to access their MOSS 2007 Mysites as

https://portal.enterprise.com/personal/username

rather than

https://mysites.enterprise.com

(which requires a different url, possibly new certificates, and probably mass confusion), then you can do no better than look to this blog entry from Chris Johnson.

http://blogs.msdn.com/cjohnson/archive/2006/09/15/754902.aspx

Site Collection Administrators and Adding Workflows to Sites with Broken Inheritance

Another gotcha in the SharePoint world. You would think that Site Collection Administrators could do anything on any site inside the collection. Being an administrator and all. Not so. If you've broken inheritance you will find that you no longer have the correct options in SharePoint Designer to add a new workflow. For the meantime I have solved this by explicitly adding the "Site Collection Administrator" account into the "SiteName Owners" group - which was created when we broke inheritance. Not exactly the functionality I was expecting.

Fear and Surprise and Permissions in MOSS Central Admin

Access denied when selecting "User profiles and properties"? Can't access your shared services provider? Can't get to the "Import Application Definition" page of the BDC?

No one expects the MOSS administration, and certainly - if you are looking at the Central Administration tool for the first time, you would certainly be forgiven for suffering from fear and surprise, the 2 weapons of the Administration.

Yes 2 are their weapons; fear, surprise and permissions...oh, no wait, that's 3. Anyway.....

As an external consultant, assisting with someone elses MOSS install, you can't always fall back on knowing the domain admin password, or being privvy to the setup accounts and passwords used for setting up the search, app pools etc. But you may need, like I do, to have access to administer everything about Central Admin after the initial setup, using a normal user account created for you by the IT team. I generally make sure this is all sorted out before I leave site the first time, along with any remote connection details required.

Giving this user account access sounds easy. The "original" administrator needs to go to Central Admin -> Operations -> Update Farm Administrator's Group, and simply add the user in. Easy! well....you'd think. Launch Central Admin with this new account and yes, you'll get in, but you'll quickly find you have no access to mysites, shared services providers or to any other site collections. However - you now have all the boot strapping you require.

First make sure you are a site collection administrator for mysites, the SSP, and any site collections you are interested in using the following procedure:

• Go to Application Management -> SharePoint Site Management -> Site Collection Administrators
• Select "change site collection" and select the correct web application using the over complex interface
• Add yourself as the secondary site collection administrator

Great - I'm a site admin of the SSP - now I can do everything I need? Sadly not...

You may have got yourself into the SSP, but you'll find that you can't access several expected key features, notable being:

• User Profiles and Properties
• Import Application Definition

To do this, you'll have to assign yourself the permissions using the links:
Personalization services permisions
Business Data Catalog Permissions

Nothing complex here - just a step that I bet you wont be expecting already being as "admin" as you can get

"fun" adding Webparts to SharePoint 2003

We're doing a bit of "retro" SP 2003 work for a client, and having written several webparts for 2003 I thought 1 more couldn't cause a problem. ha! how wrong could I be. We'll I created my webpart (see http://msdn2.microsoft.com/en-us/library/ms948909.aspx if you want a starting guide), and checked that everything was all named correctly. Then I tried to deploy the webpart (see http://www.codeproject.com/useritems/BasicWebPartPartII.asp) for another good guide.

When I couldn't get my web part to appear I checked the event log to find

"Failed to locate the assembly in the SafeControl assembly paths".

Trying to import the .dwp file directly from a team site (Modify Shared Page-> Add Web Parts -> Import) gave the similar error:

"A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as safe."

After more checking and rechecking of the .dwp file and the section of the web config I checked the virtual server. It's an older IIS 6 box, and as such was still creating sites configured for .NET 1.1 by default. Aha - I'd built my assembly with .NET 2.0. No problem, change the Virtual server over to .NET 2? Well, not quite. SharePoint is "well secure (aye)" and won't run if you do that. You need to make the further step of running stsadm to upgrade the server configuration:

stsadm -o upgrade -forceupgrade -url http://URLOftheVirtualServer

You can find full information about the problem in KB Article 894903. I really hope this saves someone the headache in these circumstances - most of the newgroup posts/replies tend generally to ignore the users actual problems, or reply with "i've fixed it" without saying what the fix was.

Access 2007 is useful! Stop Press!!!

Access has generally been the whipping boy of database products, mostly scorned by "real database developers" due to the fact that it allows users to think they can create databases. However, for the first time, I think I have seen a glimpse of something truely useful for Access 2007.

Where else might Access be useful but in MOSS 2007! Tired of your old views? bored with datasheets? Management requesting graphed reporting information from a list you wish you'd stored in SQL? "Access View" to the rescue! New in 2007 (along with Gant views - another favourite) you can produce any Access report - and better, link it directly to the list of views available from the SharePoint list.

1 - Create your view

Simply select "Access View" and it will launch Access 2007, with your list information already marked as a linked table. For this example I selected the "Pivot Table" option - surely the best demonstration of why you'd want an Access view. A quick bit of playing and I was done.

2 - Publish the result to SharePoint.

As simple as selecting the "Publish to SharePoint" option. Save the file in a document library (best make a hidden one for the purpose of access views). Make sure that when the dialog appears you say yes to adding this view to the drop down list of views available in the list.

3 - Select your view

Woohoo! Look - there is my new view. Sadly it loads Access 2007, rather than say, displaying the pivot chart directly in a web page, but I guess it is still a big step.

4 - Enjoy the results

And here is my completed pivot chart - 10mins from start to finish, no development, no reporting services, and Management can play to their hearts content.

Word 2007 Content Placeholders and the Word 2003 plugin for Office 2007

It's to Microsofts credit that they have provided a plugin for Word 2003 that will allow the reading of a Word 2007 .docx file. And it (mostly) works. If however you need to use some of the new features office 2007 - such as the content placeholders you'll find that the content inside them won't render. I'm hoping they'll fix this soon.

If you haven't checked out content placeholders you can file many articles on it, but here is a reasonable overview on content placeholders in Office 2007. It's a great new feature, but as usual not without it's limitations, such as handling repeating sub groups, and the definate need of a configuration editor that others outside the Office team have had to write.