SQL Server 2005 Partition Problems

We have a replication scenario where have SQL Server 2005 replication publications on development, test and live servers. Recently we had an issue where test server publication, having not been touched for about 3 months (between releases) suddenly stopped synchronising correctly with the following message:

The merge process failed because it detected a mismatch between the replication metadata of the two replicas, such that some changes could be lost leading to non-convergence. This could be due to the subscriber not having synchronized within the retention period, or because of one of the replicas being restored to a backup older than retention period, or because of the publisher performing more aggressive cleanup on articles of type download-only and articles with partition_options = 3

The effect was that all data seemed to come down, but the result from the synchronisation attempt was failure. A bit of googling turned up an incredibly similar issue where the partion_options=3. There is a hotfix available on request for this exact issue. Helpfully microsoft say "change this", but leave you with the usual link-to-link hell of trying to find a posting in msdn that actually tells you how to make the change.

Now in our case we were actually using partition_options=0, but I found that following the process below fixed it for me:

1. Set partion_options=1
   To do this you will need to use partition groups. Execute the following SQL against your publication database:
   
   sp_changemergepublication @publication='MyPublication', @force_invalidate_snapshot=1, @property='use_partition_groups', @value='true'


2. Then, either run stored procedure statements, or as I did, through Management Studio -> Replication -> Local Publications -> "My Publication" -> Properties -> Articles -> Article Properties -> Set Properties of all article tables
   Change the "Partition Options" from "Overlapping" to "Overlapping, disallow out-of-patition data changes"


3. Reinitialise the snapshot


4. Change the partition options back to overlapping


5. Run sp_changemergepublication @publication='MyPublication', @force_invalidate_snapshot=1, @property='use_partition_groups', @value='false'


6. Reinitialise the snapshot.

Synchronisation seems to have worked fine from this point. As this was our UAT environment there was little actual harm done, but you'd probably want to take precautions in a live environment - as unmerged data on local devices would be lost in the above process.

OWSTimer Hogging Processor Part 2

It seems there was more...

The fundamental issue on this VM environment turned out not to be the time synch issue in all probablity, but a lack of resources in the environment.

3 Server pools had been set up, dev, test and live. VMWare allocated the resources 33% to each. There were 3 live servers, and one of the servers had been given an exact memory allocation equating to most of the resources available to the server pool.

Of course, if you only ever log into your VMs through RDP then your machine will tell you how much ram the VM image believes to be in its "Hardware". The effect - VMWare Infrastructure client reports that resources are not fully utilised (so no problems) but your VM client reports maximum processor usage (normally OWSTimer is the offender when you notice, or sometimes the mssearch service.

The answer in the case of this environment was simply to remove the server pools, and allow all the servers to contend normally for the resources they required. Server pools are a double edged sword....

OWSTimer Hogging Max Processor Time in VMWare

This issue isn't exclusive to VMWare, but is much easier to come across. You may notice your MOSS server being completely unresponsive for serveral minutes at a time. On investigation you find that OWSTimer is taking up 80%-100% processor utilisation. I have particularly found this occuring on VMWare MOSS installations, and often occurs straight after you restart a VM that has been off for a significant amount of time.

The issue here is clock time synch. If the SQL Server/SharePoint server do not agree then OWSTimer gets itself in a right tizz and maxes the processor. In a VM environment this might look particularly weird - as your VM Host may be reporting plenty of resources available.

To resolve this (in WMWare)

To resolve this do the following:

• Stop and disable the OWSTimer and Windows SharePoint Services Tracing services
• Install VMWare Tools if not already installed on the SQL and SP boxes
• Right click on the VMWare System Tray icon and tick the "Time Synchronisation between the virtual machine and the console operating system
• Ensure your VM host synchronises time from your internal time synch service (ie in synch with the AD controller)
• Verify that all servers are time synched
• restart OWSTimer and Tracing services

Why does this happen so much in VMWare?

Well, VMWare has issues when the CPU goes into powersaving modes, meaning that the clocks don't correctly calculate time (eg the VM image thinks it is running at 2.4Ghz, but is actually at 1GHz), therefore gets out of synch easily. The same effect seems to occur when you power up a VM image that has been left for months.

Search Server 2008 Express RC

Today Microsoft released a bombshell: Search Server 2008 Express

In summary:

• It's free
• Standalone product
• All the features of MOSS search
• Limited to one query server – so not scalable for the very large enterprise look at the other variations if you're after this

This is going to really change the game for the low end users.

It's in RC now, so I'd think the end of Q1 will be the target launch. I'll post something in the next day or so relating my experiences with it

MOSS - Targeting content to Sites not Audiences

Audience targeting is a great way to push information to individual users from a central source - but what about when you want to push information to particular sites? My example is a series of department sites. Sounds easy - content query web part (CQWP) filtered on a choice column on your list of announcements/documents/links etc to say which department the item is relevant to. Job done? well until you need to say that this item is for multiple departments...

Try changing the choice from dropdown to "checkbox/multiple". The text that appears in a list view is great "choice1;choice2;choice3" etc. Great! lets filter using "contains" in the CQWP. Not really - while you see the value in the interface as a string, th CQWP won't when filtering - so you end up with no results? The answer? Content Types and Workflow. For the rest of this article I'm working with a document library with a "Relevant Department" column

Create a new Content Type

(mine is at the top portal level for reuse). I called mine "My Choices Content Type", inherited it from "Document" and added it to "Test Content Types" to keep it seperate. I added 2 new site columns

• MyChoices - a checkbox based choice column


• MyChoices_Text - a single line text column

Go to your document library/annoucements list/ etc and change it to allow content types, add your new content type and remove any others from the list. Don't upload any documents or create any items yet.

Create a Workflow in SharePoint Designer

Open up the site containing your document library in SP Designer. From the file menu select New > Workflow, configure yours similar to mine below:






This workflow will copy the (non-text) multiple choices into a text column, thus exposing it as text to the CQWP.

Ammend CQWP to Filter based on our content type

Now that we have this property create a CQWP on your "department" site. Configure it as below to point at our list, our content type and then filter it based on the Site Column "RelevantDepartment_Text" and use the filter operator "Contains". Enter a string matching one of your choice values. OK these choices.



Congratulations, you should now have a list of documents that can be relevant to more than one department, pushed through to the site of your choosing.

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