Microsoft Office Tutorials and References
In Depth Information
There is a good chance that, after you install and configure SharePoint, there will be a few known
errors in the event logs. Troubleshooting these errors is covered in detail in Chapter 13, “Maintenance
and Monitoring,” but I just wanted to let you know that there are known ixes for them. Here are
some brief suggestions.
For the DCOM event ID 10016 Distributed COM error in the System log; there will likely be two DCOM
objects that need to be dealt with. One is the IIS WAMREG admin service; its CLSID starts with
61738644. This is caused because SharePoint doesn’t properly give content database access accounts
the permission to launch or activate the DCOM object locally. You will need to give that account local
activation permission to the DCOM object to clear that error (or better yet, give the WSS_WPG group
permission; that way, you won’t need to do this every time a new content database account is used).
For server 2008 R2, you will first need to go the object’s corresponding key in the registry and give
the account you are logged in w ith ownership of the key and full control of it. Then you can go to the
Component Services console, select the DCOM component you need, go to its properties, and then
add the necessary account (or group) to the Launch and Activation permissions.
If you get the same event ID error, but for CLSID that starts with 000C101, then that is because the
farm account wasn’t given the correct permissions to the MSIServer DCOM object. To ix this error,
use the steps used for the other CLSID , but add the farm account to the launch and activation
permissions for the 000C101 object (it won’t be listed by its name) so it can do local activation.
In the application event log, you may also get event ID 1511 errors because the server cannot find a
local user profile for the content database account (the account causing the problem will be listed
in the error). SharePoint uses a user profile for content database accounts but just can’t seem to get
it right. So if you do have this problem, do an IISRESET on the server to unlock the profile (in case
IIS was using it). Then log in locally on the SharePoint server with the offending account. Change
some things on the desktop (if it indicates that it was using a temporary profile, make changes,
and log out and log back in again, until your changes stick and it doesn’t say it’s using a temporary
profile), then log out and log back in as your SharePoint administrator. You might want to do another
IISRESET just in case and then check the user profile properties to make sure the account now lists
as having a local profile. It might take a few tries, but that usually works.
Post-installation Configuration Tasks
At this point, you’ve finished the Complete installation for your server farm, but there are still a
few more things you need to do to have your implementation truly up and running. Specifically,
although SharePoint now has Central Administration, a SharePoint-80 web application, Search,
BDC, sandboxed code, and usage and health enabled, it is missing email.
This is because email configuration requires information that the installation process cannot
predict, and it requires custom configuration far outside of SharePoint’s control. However,
considering some of the configuration tasks you’ve done, configuring incoming and outgoing email
is pretty easy. Once that is done, you’ll need to create accounts for farm administrators, site
collection administrators, and at least one user.
Search JabSto ::

Custom Search