Using the Object Model to Manage Windows SharePoint Services 2.0
You can use the object model for Microsoft Windows SharePoint Services to manage your servers, sites, users, and other resources. To access the administrative object model for Windows SharePoint Services, you must be an administrator of the local server computer or a member of the SharePoint administrators group.
If you are using a Web application (such as a billing application) to access the object model and perform administrative functions, you must be sure that the Web application is running in the same security context as Windows SharePoint Services. In other words, the Internet Information Services (IIS) application pool for the Web application must allow access to the SharePoint administrators group, or you must include the application pool account in the SharePoint administrators group, or the application pool must be the same application pool as is used for SharePoint Central Administration.
If you are relying on the SharePoint administrators group for the security context, keep in mind that there are some actions that that group cannot perform. The following actions must be performed by a member of the local administrators group for the server computer:
Extending virtual servers or removing Windows SharePoint Services from a virtual server
Changing the configuration database settings
Changing the SharePoint administrators group
If you want to perform these tasks from a custom application that calls the administrative object model directly, the application must be running as a member of the local administrator group.
Administrative Object Model Scenarios
There are many times when it would be useful to use the object model to perform administrative tasks for Windows SharePoint Services, rather than using the command line tool or HTML Administration pages. For example, you would use the object model when:
You are using Windows SharePoint Services in Active Directory account creation mode.
Active Directory account creation mode allows you to automatically create accounts for users in the Active Directory directory service, rather than using pre-existing domain accounts. When you are in this mode, there are certain administrative tasks that are unavailable in the HTML Administration pages. For example, you cannot create a top-level Web site, you cannot enable Self-Service Site Creation, and you cannot add a user to a site from the Central Administration pages. To perform these actions in Active Directory account creation mode, you must use the object model or the command line. For more information about Active Directory account creation mode, see Managing Users and Cross-Site Groups (Windows SharePoint Services 2.0).
You have a custom administrative application that you use to manage servers in your server farm, rather than using SharePoint Central Administration.
If your environment is very complex, and your organization uses a special administrative application to manage servers, you can use the object model to call the Windows SharePoint Services administrative functions, rather than using the HTML Administration pages or the command line.
You have a Web application that needs to call into Windows SharePoint Services to perform a specific set of administrative tasks.
For example, if you have an application that coordinates online meetings, and you want to create Meeting Workspaces in Windows SharePoint Services automatically, you can use the object model to do so.
You want to generate administrative reports to track sites, usage, or other data.
You can use the object model to enumerate the sites owned by particular users, find out how many users or how many files are being added to sites, or determine trends and perform capacity planning to decide when it is time to add another server to your server farm.
You want to make site creation conditional based on billing information or generate custom pages based on billing information.
For example, you can use a billing application to verify billing information before a user can create a site. Or, you can use contact or billing information to generate a custom page that shows which sites belong to which site owners.
You want to make site access conditional based on billing or employment status.
You can use the quota mechanisms to automatically lock a site if a customer or group is not current in its billing, and only allow access when the billing charges are rationalized. Or if a user is no longer part of your organization, you can lock all sites owned by that user until you determine what to do with the sites. For more information about quotas and locking sites, see Configuring Site Collection Quotas and Locks (Windows SharePoint Services 2.0).
For more information about the administrative object model and using it to perform administrative tasks, see the Windows SharePoint Services Software Development Kit.