Usernames of some users don’t appear in People and Groups column: MOSS 2007

Last week, we have experienced a strange issue. One of the lists has a “peoples and groups” column, the usernames of some of the users didn’t seem to appear even though they are selected the same way as others. After a 3-4 hours of research, I could figure out that the issue is related to permissions and the fix is adding them to the same SharePoint group which has permissions on that library.

Here are the research steps:

1) I have granted those users “contribute” permissions on the JE library and tried uploading the JE and their names seem to appear
2) Next, I have cut-down their permissions and gave them Read-Only permissions on the JE library. It worked even with Read-Only permissions.
3) Next, I have just added them to the Finance_JE_Preparer group under the same role: JE_Preparer. It worked.

I am not sure if this fix actually makes sense but I believe this issue has something to do with the maintenance activity of re-granting the same permissions to the users in question.

Hope this helps…….


!New icon duration and update functions

We can change the “!New” indicator time span using the command:

stsadm.exe -o setproperty -pn days-to-show-new-icon -pv -url [Your Virtual Server’s URL]

If you would like to turn off the “!New” icon, set the number of days to zero.


You don’t need to do a IISRESET for ALL list items (not just documents) on the virtual server.

MOSS 2007: Search Service hangs


1. Search Service just hangs and
2. Services console: start, restart, stop options do not appear
3. Restarting the system doesn’t yield any results even


1. psconfig -cmd services -install
2. Configure Search again and see the magic


This is not effectively tested. So, the implementation of this fix to the Production environment carries a risk. Please consider.

Event ID 5555 & 7888

Failure trying to synch web application 7eac22d3-dcc7-4744-b42d-4f627e46d6a8, ContentDB 71c3ed5d-540a-4355-8bc7-ed9478586dd5 Exception message was A duplicate site ID 9cb926f0-148d-4211-aed5-f22620b1dcac was found. This might be caused by restoring a content database from one server farm into a different server farm without first removing the original database and then running stsadm -o preparetomove. If this is the cause, the stsadm -o preparetomove command can be used with the -OldContentDB command line option to resolve this issue.


run stsadm -o sync -DeleteOldDatabases 0

It will delete all the references to old databases and deletes connections to any old Sharepoint config database that you may have on your server.