Find closed web parts all over your portal

For most users, it's very common to close, instead delete a web part from pages, especially the landing page of a site. As an administrator, you can go to each page and open web part maintenance page to check and removed closed ones.

However, how do we find out which site has the most and deal with them first if you have hundred of sites to manage? You can use a SQL query to geerate a list. (MIcrosoft said do not touch your database, so, this is just for your own reference and risk).

select ''+dirname+'/'+ leafname+'?contents=1'
from alldocs inner join webparts on
Alldocs.id=webparts.tp_pageurlid
where tp_isincluded=0

Work Around STSADM Import/Export Failure

We have been using STSADM Import/Export features to reorganize the entire MOSS content structure. Sometimes we saw fatal or too many error during importing process, especially when we worked on site collections with large number or size of contents.

After couple tries, we found that if we choose not to compress the exported files, it really helped to draw down the chance to have errors.

If you experienced similar situation, try this work around and let me know if it really helps you.


Enjoy.

MOSS and High CPU Usage - a rare case

Earlier this week in the afternoon we noticed that the production MOSS was running very slow. Our team found out the CPU usage of the WFE server was reaching 100% constantly. The WFE had 8 cores with 4 GB memory and hard to believe it's normal.

I was on the way home and driving, so I could only help with my mouth bfore I could open my computer and connect to the server. We reset IIS couple times and the same situation would come back after 10 to 15 minutes. We could not reboot at the time due to the users from the west still using it.

So the next thing we did was to find out what may cause this CPU spike. When we traced the time line back, the major difference was that one site collection was restored with DocAve earlier in the afternoon. We decided to narrow down the range by restoring the same site collection to our development environment.

Then the same situation happened in the development sever and we knew that's the source. But why? By going through some emails and conversation with different users, we thought it has something to do with InfoPath form. But we still did not have anything clear.

In order to put production MOSS back to normal status, we communicated to the site owners with the situation and our work around solutions: backed up the site collection and removed it from the system until we know how to open it again without problem. Very soon we had approval from the owner and proceeded.

We backed up the site collection, removed it from production, reset IIS and restarted coupld services. Everything looked fine and CPU usage staied low for 30 to 40 minutes. We knew the crisis in production was over and we can concerated on finding the answers.

Our techinical lead took another site collection which had InfoPath from and restored it with DocAve to development enevironment. The same situation came back right away. Now we knew something wrong with DocAve and InfoPath form.

We sent our finding and a sample to the vendor and they could reproduce the same problem in their lab. So, DocAve can not deal with site which has InfoPath form?

Not really. This is a very rare case: in order to have this problem, you have to have a InfoPath 2003 form template saved in a library which was migrated from WSS 2 (not sure the same would happen to 2003 Portal). When you restore the site with DocAve, you will have the same problem. However, if you restore the entire site collection with STSADM, no problem at all.

We received a patch from the vendor and tested it. So far it looks good. So, case closed.

STSADM Export/Import Problems

In the past 1 1/2 month, our team is working on to re-organize the portal site structure. Before we migrated last December, there were more than 150 site collections and more than 700 sub sites. In our plan, we are going to put them into one portal and 9 departmental site collections. From 150 plus to 10 site collections, I believe this is a big efforts to move 85 GB database around multiple databases.

The first tool we consider is, of course, STSADM. This is the out-of-box tool from Microsoft, support by Microsoft and what can go wrong, right?

Actually, lots things can go wrong and so far I haven't found lots information from on line sources. So far the problems we have seen include:

1. Not all document versions are imported correctly. I did some research through database and so far I have one clue. There is a column called DocFlag in both AllDocs and AllDocVersions tables. If any record in AlldocVersions has a different DocFlag values than the current version, import process skipped this one.
2. Sometimes all of the versions are replaced by the current one, which means the date and author are also replaced.
3. Import operation can not process the Project Tracking list properly and I have no clue.
4. Sometimes not all sub sites, lists, libraries or items are not imported and I have no clue how to predicted. If I redo import or export/import, I can get everything correctly.
5. The import log does not show you all information. For example, you can find each version of a document is exported from the log, the same information is missing from the import log.
6. Do I mention all of these problems are hard to predicted? I have no idea if I wrong export/import to the same site collection multiple time, when do I get and which problems.
7. The biggest one and also no way to predict it: sometime when you import from an site collection to a group of sub sites, the original top-level site does not import to the correct sub site. The whole contents go to the top-level site of the new URL and overwrite the one. I have no clue or information why and how it happened.

After very intensive testing and evaluation, we decided not to use STSADM as the tool to do this re-organization. One major concern is we have no way to predict when and where the problems will strike us.

If you have any way to resolve the problems I just mentioned, I am all ears. Thanks in advanced.

Where to find the thrid site collection administrator?

When either the server or site collection administrator (depends on you have self-service turn on or not) creates a new site collection, the administrator has two field to enter at least the primary site collection administrator. This information is saved in the OwnerID and SecondaryContactID.

After the site collection is created, the site collection administrator is able to remove, change or add more than two site collection administrators to the list. If you remove a name from the list, MOSS will remove it from one of the column. When you add the same name back, or add the 2nd administrator to the list, you will not see the column updated by the system.

On the other hand, since there are just two columns, where the setting is saved if you add another administrator?

This is actually what happened when you make changes to the site collection administrator list:

1. When you add up to two names to the fields during site collection creation, both names are saved in the Sites table.
2. When you remove anyone from the list after the site collection is created, MOSS will remove it from the Sites table.
3. If you add a new name, no matter this is the 2nd , 3rd or more, MOSS will not update the Sites table.
4. All the changes made to the site collection administrator list go to UserInfo table. There is a column called SiteAdmin and this is the place you can do your search.