IT and DEV

"In case if you don't know there is a hidden list named "User Information List" which displays all the users of the site (collection) {MOSS / Sharepoint 2007}. And there is a page "Simple.aspx"  which show this list, the URL for the page would be http://YOURSITENAME/_catalogs/users/simple.aspx."

Gregory S. MacBeth : User Profiles

Labels: moss, sps, tips

There have been a few occasions in the past where I found myself wondering why a scheduled spsbackup crashed on me. It always boiled down to a lock on the Sharepoint Configuration Database, which could only be removed by starting another backup with spsbackup.exe and removing the lock when prompted. These locks were often the result of an earlier Scheduled spsbackup crashing because of -for instance- scheduled maintenance on the farm.

However, just today I came across another locking problem. Having restored a 160GB backup set from one of the production farms to another testfarm, all kind of weird issues started popping up. When I tried to change the Farm Topology (sometimes a jolt here and there does the trick), Central Administration came back with this Warning:



So now we have two possible instances where Spsbackup-related locks can be found:

1. When a spsbackup backup run doesn't complete succesfully
2. After a spsbackup restore performed with spsbackup.

Luckily Central Administration was kind enough to provide a killswitch, which worked like a charm!

Labels: sps

I've spent last week searching through logs for a clue as to why a Portal has been so slow to respond to page requests; sometimes as long as 70+ seconds...

We haven't discovered what causes the delay yet, but what we have discovered is that the worker process memory usage gradually grows to the maximum 800 MB. This is when the response-time issue start to happen. This usually takes place during the day when Portal usage is expected to be high.

So far we've been able to create a temporary workaround by adding a third web frontend to the Sharepoint Portal Server farm. The cause of the memory fillup followed by the large response times is as yet unknown.


Moral to this (continuing) story:

If there are no obvious signs (CPU/Memory/IO) as to why your Portal is reacting so slow to user requests and you want to find the cause, there are three pieces of the puzzle you want to have to be able to do some serious troubleshooting:

1. User statistics. Think IIS logging.
   Why? You want to be able to compare usage to any other statistics gathered from your systems.
2. System Statistics. This can be anything from ASP.NET counters to network usage to SQL tracing. Basically, how is your farm/infrastructure behaving?
3. Webpart architecture. This is especially important if there has been some serious webppart programming going on in your Portal environment. Even more so if external datasources are accessed. Think web services, databases etc.

Bottom line

When webparts are introduced in your Portal System they will alter the behaviour of your Portal farm. Don't be caught off-guard.

Labels: sps

# posted by Martijn Plijnaer : 20:52  0 Comments Links to this post