Class store schema6389589Abstract A schema that facilitates the centralized management and deployment of applications, components and services across a computer network. Centralized class stores are provided under policies associated with a directory container such as a site, domain or organizational unit. Class stores include definition, state and location information for applications and components, such that applications and components are centrally available as needed. For example, via the class store, updates to components or applications for users under an organizational unit are performed once in a centralized location, whereby users or machines may automatically obtain new versions of applications as they become available, or software implementations as needed from a centralized repository. Class stores may be configured to contain packages of component and application information according to functional areas, level of security access, or other criteria as determined by an administrator. Component categories (e.g., spreadsheet, word processor, and so on) may also be maintained, whereby a suitable application may be located by its function. For customized administration and programmatic query or installation of specific components and packages, the class store also includes a manager object that offers a set of interfaces and APIs. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
Common-Name Class-Store
Admin-Display- Class-Store
Name
Admin- Class-Store
Description
Object-Class Class-Schema
Comment Class store container
LDAP-Display- ClassStore
Name
Governs-ID 1.2.840.113556.1.5.44
Class Type Structural Class
Rdn-Att-Id Common-Name
Schema-ID-GUID {bf967a84-0de6-11d0-a285-00aa003049e2}
Default UI Hidden
State
System-Only FALSE
Default- D: (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA) (A;;RPWPCR
Security- CCDCLCLORCWOWDSDDTSW;;;SY) (A;;RPLCLORC;;;AU)S: (A
Descriptor U;SAFA;WDWOSDDTWPCRCCDCSW;;;WD)
Subclass of Top
Poss-Superiors Container;Domain-DNS;Organizational-Unit;Class-
Store;User;Group;Computer;Domain-Policy
MAY contain App-Schema-Version
Last-Update-Sequence
Next-Level-Store
Version-Number
Applications and components are generically referred to as packages, and as shown in FIG. 3, are stored under the CN=Packages container 72. The Directory object class for these objects is Package-Registration. Key Fields include File-Extension, Com-ClassId, Categories and ProgID. Relationships include N-to-N with ClassIDs, and N-to-N with Application Categories. The following table, TABLE 2 describes a package container object:
TABLE 2
Common-Name Package-Registration
Admin-Display- Package-Registration
Name
Admin- Package-Registration
Description
Object-Class Class-Schema
Comment Class store: registration information for an
application
LDAP-Display- Package Registration
Name
Governs-ID 1.2.840.113556.1.5.49
Class Type Structural Class
Rdn-Att-Id Common-Name
Schema-ID-GUID {bf967aa6-0de6-11d0-a285-00aa003049e2}
Default UI Hidden
State
System-Only FALSE
Default- D:
Security- (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
Descriptor (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU) S:
(A U;SAFA;WDWOSDDTWPCRCCDCSW;;;WD)
Subclass of Top
Poss-Superiors Class-Store
MAY contain Can-Upgrade-Script
Categories
COM-ClassID
COM-InterfaceID
COM-ProgID
COM-Typelib-Id
COM-Unique-Package-ID
Execution-Context
File-Ext-Priority
File-Extension
Icon-Path
Install-Ui-Level
Last-Update-Sequence
Locale-ID
Machine-Architecture
Managed-By
Msi-File-List
Msi-Script
Msi-Script-Name
Msi-Script-Path
Msi-Script-Size
OS-Version
Package-Flags
Package-Name
Package-Type
Product-Code
Setup-Command
Upgrade-Product-Code
Vendor
Version-Number-Hi
Version-Number-Lo
Classes (ClassIDs) are stored under the CN=Classes container 74. The Directory object class for these objects is Class-Registration, key fields include ClassID and ProgID, and the relationships are N-to-N with Packages and N-to-N with Component Categories. The following table, TABLE 3 describes a class container object:
TABLE 3
Common-Name Class-Registration
Admin-Display- Class-Registration
Name
Admin- Class-Registration
Description
Object-Class Class-Schema
Comment Class Store: Registration information for a COM
Object
LDAP-Display- ClassRegistration
Name
Governs-ID 1.2.840.113556.1.5.10
Class Type Structural Class
Rdn-Att-Id Common-Name
Schema-ID-GUID {bf967a82-0de6-11d0-a285-00aa003049e2}
Default UI Hidden
State
System-Only FALSE
Default- D:
Security- (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
Descriptor (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
S: (AU;SAFA;WDWOSDDTWPCRCCDCSW;;;WD)
Subclass of Leaf
Poss-Superiors Class-Store
MAY contain COM-CLSID
COM-InterfaceID
COM-Other-Prog-Id
COM-ProgID
COM-Treat-As-Class-Id
File-Extension
Implemented-Categories
Managed-By
MIME-Types
Required-Categories
Each application in an organizational unit may be categorized so as to belong in a set of categories, such as "spreadsheet" or "word processor." Application categories are domain specific, and are maintained by a domain administrator. When an application is published, the administrator may associate it with any number these defined categories. Categories are used to enable the desktop user to select a published application (described below) through the Add/Remove Programs applet or the like. Application categories are GUID values associated with descriptions, which are locale-specific string values. Descriptions for any number of locales may be stored for a given category. Categories are maintained (added, removed, renamed) using IClassAdmin methods, described below. Global Component Categories are stored under the CN=Categories container. The Directory object class for these objects is Category-Registration, while Key Fields include ImplementedClassID, RequiredClassId, and relationships are N-to-N with Classes. TABLE 4 describes a component category object:
TABLE 4
Common-Name Category-Registration
Admin-Display- Category-Registration
Name
Admin- Category-Registration
Description
Object-Class Class-Schema
Comment Class store: registration information for a
component category
LDAP-Display- CategoryRegistration
Name
Governs-ID 1.2.840.113556.1.5.74
Class Type Structural Class
Rdn-Att-Id Common-Name
Schema-ID-GUID {7d6c0e9d-7e20-11d0-afd6-00c04fd930c9}
Default UI Hidden
State
System-only FALSE
Default- D:
Security- (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)
Descriptor (A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
S: (AU;SAFA;WDWOSDDTWPCRCCDCSW;;;WD)
Subclass of Leaf
Poss-Superiors Class-Store
MAY contain Category-Id
Locale-ID
Localized-Description
Managed-By
The class store 70 thus includes a variety of properties and relationships for each of its various application packages. In general, as set forth in TABLE 2 (above), these include deployment state of the application, global details such as deployment name, publisher of the application, version, and a source for additional information. Also included is installation specific information, used for causing the application to be partially or fully installed on a desktop, activation specific information, used for finding the correct application to launch for an OLE or Shell activation, including, ClassID, File Extension and ProgID associations of the application. Platform specific information is also included, providing information on which hardware architecture and what operating system (and versions thereof) are required to run the application, along with specifying a set of supported locales. Moreover, upgrade relationships with other applications is included. In accordance with one aspect of the present invention, the class store 70 and the containers 72, 74 and 76 thereunder thus provide the information for deploying applications in a network. In particular, two important mechanisms for deploying applications are supported, referred to as Assigning and Publishing, as described in copending U.S. Patent Applications entitled "Method and System for Assigning and Publishing Applications" and "Method and System for Advertising Applications," assigned to the Assignee of the present invention, filed concurrently herewith, and hereby incorporated by reference herein in their entireties. In general, an assigned application is an application that is explicitly made available to users in a group or organizational unit into which it has been deployed. Assigned applications appear to be installed on a desktop, such as by appearing in the Start Menu and/or on shortcut icons on the desktop, and the user is not required to perform any special action to get an assigned application. More particularly, assigned applications are advertised as being available by default, i.e., relevant registry entries, Start Menu links, shortcuts and icons (i.e., advertising binaries) are automatically placed on the machine at user logon. Note that if the application is assigned to a user, it is available to that user on any machine onto which the user logs on, while if the application is assigned to a machine, then it is available to all users who log on to that machine. An assigned application may be started by clicking on a file having an extension associated with that application (e.g., Microsoft.RTM. Word for a .doc file) or via ClassId based activation. Note that the executable code and the like of an assigned application may not be physically loaded on the machine at logon. Instead, the application is advertised as being installed, after which the first use of an assigned application on a machine may trigger appropriate pieces of the application to be copied onto the machine. To enforce assigned application policy, when an assigned application is uninstalled, orphaned or upgraded, a subsequent logon (user) or reboot (machine) causes the correct application to be advertised on the desktop, as described below with particular reference to FIG. 5A. Alternatively, a published application is an application that is available to users in a group or organizational unit into which it has been published, however unlike assigned applications, published applications do not appear installed on a desktop. For example, the administrative action of publishing an application does not make a reference to that application appear in a user's Start Menu. In general, a published application has no presence on a user's machine until the published application is automatically or manually installed on a desktop, i.e., the application becomes assigned to the user's profile. More particularly, published applications (those set for auto-install) are automatically assigned to a user's profile when activated by clicking on a file with an associated file extension or via ClassID activations. Moreover, a user may manually install a published application such as via an "Add/Remove Programs" applet dialog box or the like. Once a published application is installed, the user sees the application as if it was previously assigned, however, unlike an assigned application, if the published application is removed, it will not be present at the next user logon. In general, deployed applications in the Class Store may be in one of the states set forth in TABLE 5, below:
TABLE 5
Assigned
Published with AutoInstall
Published with no AutoInstall
Minor Revision (Patch)
Upgraded with uninstall
Upgraded without Uninstall
Uninstall
Orphan
Pilot Deployment
More particcularly, the deployment state is maintained in the Package Flags, (TABLE 2), a set of bit flags that indicate the deployed state of an application, as set forth in more detail in TABLE 6 (only certain combinations of the flags are valid):
TABLE 6
ACTFLG_Published Application is in Published State.
ACTFLG_Assigned Application is in Assigned State;
Will be mandatory, made available.
ACTFLG_UserInstall May be installed by desktop user
using Add/Remove Programs applet.
ACTFLG_OnDemandInstall May be automatically installed
during activation by Shell/OLE/VB
based on a File Extension, CLSID
or ProgId.
ACTFLG_Orphan This application is Orphaned. It
is no longer deployed, and all
existing installs may be left as
is.
ACTFLG_Uninstall This application is to be
Uninstalled on all desktops where
it was installed as a result of
this deployment.
ACTFLG_Pilot This application is available as a
Pilot Only. As such it is not
deployed, but may be installed
using Add/Remove Programs.
Also maintained are Policy Removal Action Flags, which denote whether the application is set to be Orphaned or Uninstalled when a policy to which the application belongs is removed, as shown below in TABLE 7. In the absence of either setting, the default setting for the Policy will apply.
TABLE 7
ACTFLG_OrphanOnPolicyRemoval Orphan the application
when Policy is removed.
ACTFLG_UninstallOnPolicyRemoval Uninstall the
application when Policy
is removed.
Additional state information maintained with an application (TABLE 2) includes a Last Update Time Stamp, indicating the Time when the package or its deployment properties were last modified. Also, installation-related information maintained with an application includes a packaging type, which describes the packaging or binary format, (e.g., MSIPackage, EXEPackage, DLLPackage and CABPackage), and a file path for script, which identifies the UNC or HTTP path for the package file. For an MSI package, this is the advertisement script (.aas file), and for an EXE, DLL or CAB package this is the EXE, DLL or CAB file. Also maintained for an application (TABLE 2) is state information to be used at the time of package installation, identifying which other applications this package may upgrade or overwrite. For each script it can upgrade, the manner in which it upgrades may be set as "Overlay" (install over the other application), or uninstall the other before installing this application. Overlay and uninstall before installing are described below with particular reference to FIG. 5B. OLE and Shell activation properties may also be provided (TABLE 2) to associate a package with the object Classes (ClassIDs) implemented thereby, if any. ProgIDs provide user-friendly names for the Object Classes, while file types (based on File Extensions) are listed that the package knows to deal with, e.g., open, edit and/or print. In the event that multiple published applications are able to understand and service a particular file type, the directory may have administrator-specified priority to determine the application to be selected for a given file type. Additionally, COM Interfaces or Type-Libraries may include definition or marshalling information therewith. Also maintained in the schema (TABLE 2) is product-related information, i.e., a Major and Minor version number of the product, and a serial revision tracking number, a DWORD that tracks the revision number for an application. Each patch applied to the corresponding application increments this sequence number. A product code in the form of a GUID provides the unique family identification of the product, and the publisher of the application is maintained. Lastly a Help URL may provide the URL of a web-site for additional information about the application. For customized administration and programmatic query/installation for specific components and packages, the class store also offers a set of interfaces and APIs. As shown in FIG. 4, a Class Store Manager object 80 provides a consolidated query of one or more class stores, using a suitable protocol such as LDAP or ADSI 88 to obtain the information. The manager 80 exposes an interface, IclassAccess, to provide access to information about applications, components, and services in a class store (e.g., 70), and also provides an interface for query by Component Category, ICatInformation. Individual class store providers expose the IClassAdmin interface, which administers a specific class store container. The following sets forth the Class Store APIs and interfaces: CsCreateClassStore STDAPI CsCreateClassStore (LPOLESTR szCsPath) This API creates an empty Class Store for the specified group policy. CsGetClassStore STDAPI CsGetClassStore(LPOLESTR szCsPath, void **ppIClassAdmin) This API takes the Active Directory DN for a Class Store and returns an IClassAdmin interface pointer for it. CsDeleteClassStore STDAPI CsDeleteClassStore(LPOLESTR szCsPath) This API takes the Active Directory DN for a Class Store and removes the Class Store and thereby removes Application management Policy for the Group Policy. CsGetClassStorePath STDAPI CsGetClassStorePath(LPOLESTR szPolicyPath, LPOLESTR *pszCsPath) This API takes the DN of a group policy object and returns the class store DN if there is application policy in force. CsSetClassStorePath STDAPI CsSetClassStorePath(LPOLESTR szPolicyPath, LPOLESTR szCsPath) APIs--Getting a List of App Categories CsGetAppCategories STDAPI CsGetAppCategories (APPCATEGORYINFOLIST *pAppCategoryList) This API returns the complete list of Application Categories GUIDs and Descriptions for a given Locale. Add/Remove Programs applet/wizard and the Application Deployment Editor (ADE) call this API to get the definitive list of Application Categories. APIs--Queries and Enumeration.
CsEnumApps
STDAPI CsEnumApps (LPOLESTR pszPackageName,
GUID *pCategory,
ULONGLONG *pLastUsn,
DWORD dwAppFlags,
IEnumPackage **ppIEnumPackage);
This API is used to get applications deployed for user or machine policy. Filters may be specified to narrow the selection by "changes since," deployment flags and application category. This API returns an interface pointer for an enumerator (IEnumPackage) that can be used to enumerate using an appropriate set size. Depending upon whether this API is called under User credentials OR LOCAL SYSTEM credentials, either the user or the machine policy is used. The enumerator works across all class stores in the user's or machine's profile. This API is used by Add/Remove programs to select Corporate Apps and from winlogon to process application policy at logon, and is equivalent to calling CsGetClassAccess to get an IClassAccess pointer and then calling EnumPackages method on this pointer.
CsGetAppInfo
STDAPI CsGetAppInfo (uCLSSPEC * pclsspec,
QUERYCONTEXT * pQueryContext,
PACKAGEDISPINFO * pPackageInfo);
This API is used to search for applications or COM component implementations that can satisfy activation request from COM (OLE) 82 or Shell 84. This supports on-demand install by finding if a deployed application would be able to satisfy the CLSID, File Extension or ProgID based activation. The on-demand installation of software implementations including applications is described in copending United States Patent Applications entitled "Method and System for On-Demand Installation of Software Implementations" and "Software Implementation Installer Mechanism," assigned to the same assignee as the present invention, filed concurrently herewith and hereby incorporated herein by reference in their entireties. Note that the user's policy is used, i.e., the search is applied to the class stores in the user's policy from bottom to top order, whereby the lowest Organizational Unit with application policy takes precedence. This API is used by COM object activation when an implementation is not found in the local machine, as described below. It is also used by a Shell 84 application launch when a file extension based activation does not find an application for a file extension in the local registry. Note that this API is equivalent to calling CsGetClassAccess to get an IClassAccess pointer and then calling GetAppInfo method. CsGetClassAccess STDAPI CsGetClassAccess(IClassAccess ** ppIClassAccess); This API returns a IClassAccess interface pointer for the application policy. The interface pointer may be used to invoke methods to query into or enumerate applications that are deployed. Depending upon whether this is called under User credentials OR LOCAL SYSTEM credentials either the user or the machine policy is used. APIs--Free Data Structures
STDAPI ReleasePackageInfo
(PACKAGEDISPINFO *pPackageInfo);
STDAPI ReleasePackageDetail
(PACKAGEDETAIL *pPackageDetail);
STDAPI ReleaseAppCategoryInfoList
(APPCATEGORYINFOLIST *pAppCategoryInfoList);
These APIs free data structures allocated by Class Store APIs. Class Store Interfaces
Interface IClassAccess
IClassAccess::GetAppInfo
HRESULT GetAppInfo(
[in] UCLSSPEC *pClassSpec,
[in] QUERYCONTEXT *pQryContext,
[out] PACKAGEDISPINFO *pInstallInfo
typedef union switch (DWORD tyspec)
{
case TYSPEC_CLSID:
CLSID clsid;
case TYSPEC_IID:
IID iid;
case TYSPEC_TYPELIB:
GUID typelibID;
case TYSPEC_FILEEXT:
LPOLESTR pFileExt;
case TYSPEC_MIMETYPE:
LPOLESTR pMimeType;
case TYSPEC_PROGID:
LPOLESTR pProgId;
case TYSPEC_FILENAME:
LPOLESTR pFileName;
case TYSPEC--JAVACLASS:
LPOLESTR pJavaClassName;
case TYSPEC_PACKAGENAME:
struct {
LPOLESTR pPackageName;
GUID GpoId;
} ByName;
case TYSPEC_SCRIPTNAME:
struct {
LPOLESTR pScriptName;
GUID GpoId;
} ByScript;
} uCLSSPEC;
This method is used to search for applications or COM component implementations that can satisfy activation requests from COM (OLE) 82 or Shell 84, thereby supporting on-demand install by finding if a deployed application would be able to satisfy the CLSID, File Extension or ProgID based activation. Note that the user's policy is used, i.e., the search is applied to the class stores in the user's policy from bottom to top order, whereby the lowest Organizational Unit with application policy takes precedence.
IClassAccess::EnumPackages
HRESULT EnumPackages (
[in, unique] LPOLESTR pszPackageName,
[in, unique] GUID *pCategory,
[in, unique] ULONGLONG *pLastUsn,
[in] DWORD dwAppFlags,
[out] IEnumPackage **ppIEnumPackage
);
Class Store package enumeration. This method returns an Enumerator interface that allows accessing the list of application packages deployed to an user.
Interface IClassAdmin
IClassAdmin:AddPackage
HRESULT AddPackage(
[in] LPOLESTR pszPackageName,
[in] PACKAGEDETAIL *pPackageDetail
);
IClassAdmin::RemovePackage
HRESULT RemovePackage(
[in] LPOLESTR pszPackageName,
[in] DWORD dwFlags
);
IClassAdmin::ChangePackageProperties
HRESULT ChangePackageProperties(
[in] LPOLESTR pszPackageName,
[in, unique] LPOLESTR pszNewName,
[in, unique] DWORD *pdwFlags,
[in, unique] LPOLESTR pszUrl,
[in, unique] LPOLESTR pszScriptPath,
[in, unique] UINT *pInstallUiLevel,
[in, unique] DWORD *pdwRevision
);
IClassAdmin::ChangePackageCategories
HRESULT ChangePackageCategories(
[in] LPOLESTR pszPackageName,
[in] UINT cCategories,
[in, size_ GUID *rpCategory
is(c-
Categories)]
);
IClassAdmin::SetPriorityByFileExt
HRESULT SetPriorityByFileExt(
[in] LPOLESTR pszPackageName,
[in] LPOLESTR pszFileExt,
[in] UINT Priority
);
IClassAdmin::EnumPackages
HRESULT EnumPackages(
[in, unique] LPOLESTR pszFileExt,
[in, unique] GUID *pCategory,
[in] DWORD dwAppFlags,
[in, unique] DWORD *pdwLocale;
[in, unique] CSPLATFORM *pPlatform,
[out] IEnumPackage **ppIEnumPackage
);
IClassAdmin::GetPackageDetails
HRESULT GetPackageDetails(
[in] LPOLESTR pszPackageName,
[out] PACKAGEDETAIL *pPackageDetail
);
IClassAdmin::GetAppCategories
typedef struct tagAPPCATEGORYINFO
{
LCID Locale;
LPOLESTR pszDescription;
GUID AppCategoryId;
} APPCATEGORYINFO;
typedef struct tagAPPCATEGORYINFOLIST
{
DWORD cCategory;
[size.sub.-- APPCATEGORYINFO *pCategoryInfo;
is(c-
Category),
unique]
} APPCATEGORYINFOLIST;
HRESULT GetAppCategories(
[in] LCID Locale,
[out] APPCATEGORYINFOLIST *pAppCategoryList
);
IClassAdmin::RegisterAppCategory
HRESULT RegisterAppCategory(
[in] APPCATEGORYINFO *pAppCategory
);
IClassAdmin::UnregisterAppCategory
HRESULT UnregisterAppCategory(
[in] GUID *pAppCategoryId
);
IClassAdmin::Cleanup
HRESULT Cleanup(
[in] FILETIME *pTimeBefore
);
Interface IEnumPackage
typedef struct tagPACKAGEDISPINFO
{
LPOLESTR pszPackageName;
DWORD dwActFlags;
CLASSPATHTYPE PathType
LPOLESTR pszScriptPath;
LPOLESTR pszPublisher;
LPOLESTR pszUrl;
UINT InstallUiLevel;
ULONG cScriptLen;
ULONGLONG Usn;
DWORD dwVersionHi;
DWORD dwVersionLo;
DWORD dwRevision;
GUID ProductCode;
GUID *pClsid;
GUID GpoId;
LPOLESTR pszPolicyName;
UINT cUpgrades;
[size_is(cUpgrades)] LPOLESTR *prgUpgrade-
Script;
[size_is(cUpgrades)] DWORD *prgUpgrade-
Flag;
} PACKAGEDISPINFO;
interface IEnumPackage : IUnknown
{
HRESULT Next(
[in] ULONG celt,
[out, size_is(celt), length_is(*pceltFetched)]
PACKAGEDISPINFO *rgelt,
[out] ULONG *pceltFetched
);
HRESULT Skip(
[in] ULONG celt);
HRESULT Reset();
HRESULT Clone(
[out] IEnumPackage **ppenum);
}
The methods are standard IEnumXXX methods and have similar semantics. Next ( ) allows enumeration of the next celt number of packages, Skip ( ) lets the caller skip celt number of packages during enumeration, Reset ( ) sets the starting point back to the first package in the set and Clone ( ) creates an identical enumerator instance. For each package the following information is returned:
TABLE 8
PszPackageName: Deployment name of Package.
DwActFlags: Deployment state.
PathType: Package Type.
PszScriptPath: Script Path for Package
CscriptLen: Size of the Script for the Package
PszPublisher: Name of Package Publisher.
PszUrl: URL where more info is available.
InstallUiLevel: UI Level for installation.
Usn: Deployment name of Package
DwVersionHi: Package Major Version Number
DwVersionLo: Package Minor Version Number
DwRevision: Package Revision Number
ProductCode: MSI Product Code
Pclsid: If a COM component, one CLSID the package implements.
GpoId: Policy GUID of the group policy package is deployed
PszPolicyName: Policy Name of the group policy package is
Deployed
Cupgrades: Number of Upgrade relationships
PrgUpgradeScript: Script that has upgrade relationship
PrgUpgradeFlag: Type of upgrade relationship
.cndot. Upgrade
.cndot. Upgrades w/Uninstall
.cndot. UpgradedBy
Turning to an explanation of how the class store schema is utilized to implement application deployment policy, FIGS. 5A-5B represent the general steps taken upon user logon. Note that machine policy is similarly applied upon machine reboot, but for purposes of simplicity is not described in detail herein. In general, at logon, the Class Stores (such as the class store 70) are queried by the client-side class store manager 80 to determine what application processing is required. The processing is based on what applications are already installed by the user and what applications are assigned to the user. Note that installed applications may either be previously assigned applications or published applications that the user has installed. FIG. 5A shows the general steps for processing assigned applications at each user logon, beginning at step 500 wherein the class store 70 (and any other associated class stores) is queried via a suitable API for the assigned application and accompanying information. At every logon, the applications currently assigned to the user are advertised into the desktop to ensure that policy is enforced. This action prevents the user from uninstalling an assigned application and, for example, installing another application for the same functionality, since at each logon, the application identified in the class store under the policy object is advertised. To this end, at step 502, the first assigned application is selected, and at step 504 is advertised, which typically includes adding the application to the start menu and possibly adding a shortcut icon to the desktop, and writing appropriate information into the system registry. Step 506 causes the processing to repeat for the applications assigned to the user in the class store or stores associated with the user's group policy objects (which in turn are associated with the user's domain and organizational units). FIG. 5B generally shows the processing of applications that are installed on the user's machine, based on the state information maintained in the class store corresponding to each such application as described above. At step 520, the first installed application is selected, and at step 522, the state information therefor is obtained from the class store using an appropriate API as also described above. Step 524 tests to see if this application is to be uninstalled, i.e., the administrator has marked this application to be removed from the user's profile. If so, step 524 branches to step 526 to uninstall the application, after which step 528 tests to see if another application is to be installed in its place. If so, step 530 is executed to install the replacement, typically a new version of the application. Note, however, that the application is not necessarily physically downloaded to the machine at this time, but rather, is only advertised as being installed. If at step 524 the selected application is not to be uninstalled, step 524 instead branches to step 532 to test if the application was marked for overlay, i.e., another application will be installed essentially over this one, typically handling any uninstall operations as part of its own install procedure. For example, some programs may be upgraded by simply overwriting certain executable files and dynamic link libraries with new ones, whereby the overlay option is desirable. In any event, if an application is marked for overlay, step 532 branches to step 534 to perform the overlay install operation. If not marked for overlay at step 532, step 532 branches to step 536 to determine if the selected application has been revised, i.e., has a patch that needs to be applied thereto. If so, step 538 is executed to install the patch, otherwise no action is taken with this application. Step 540 repeats the process for each installed application. In this manner, via the class store schema, application deployment policy is implemented for a given user on a given machine. While FIGS. 5A and 5B handle assigned and installed applications, the concept of publishing applications also provides significant administrative benefits. One significant benefit to publishing applications is to let the operating system locate such applications and install them only as needed. This is possible for applications that advertise their services to Shell or OLE in terms of the File Types, the ClassID, the ProgID serviced by those applications. For example, as shown in FIG. 6, when a desktop user tries to activate launch an application that can open a particular file type or OLE embedding (step 600), Shell 84 or COM (OLE) 82 first look in the registry for the appropriate application information (step 602) to satisfy the launch request (step 604). If such an application is not installed locally and is published (step 606), Shell or OLE performs a Directory lookup, finds the application and installs it (step 608), without any prompting of the user. By way of example, consider a user receiving a Microsoft.RTM. Word document. The user opens the document, finds a flowcharting diagram embedded therein, and clicks on it to edit the diagram with an appropriate application. OLE (COM 82) looks in the registry for the CLSID of the embedded diagram and does not find it. However, an appropriate flowcharting application is published in the directory for this user's Organizational Unit, i.e., is identified in an application package of a class store under the organizational unit's policy. The class store manager 80 looks up the Directory to find a package that implements this CLSID, that is available to the user or machine, and is compatible with the processor and operating system of the machine. A Directory lookup returns the information necessary to assign this application into the user's profile, whereby the application is assigned to the user profile for this user, appropriate portions of the application are downloaded, and the user is able to view and/or edit the diagram. Note that for purposes of security, the Directory Lookup only selects packages that have READ access (e.g., in an Access Control List) for the user. In another example, consider a user browsing a file server and finding a sample spreadsheet, abc.xls. When the user clicks on the spreadsheet file to open it, Shell 84 looks in the registry for the File Extension .XLS, but does not find it. However, Microsoft.RTM. Excel97 is published for this user's Organizational Unit. A directory lookup returns the information necessary to assign Excel97 into this user's profile, whereby Excel97 is assigned to the user profile for this user, appropriate portions of the application are downloaded, and the user is able to view and/or edit the spreadsheet. In sum, when an application that can service a request is not found in the local profile, Shell or OLE make a Class Store lookup to find and install a Published Application, if there is one, that can service the request. Note that the Directory lookup takes into account the type of activation. Shell or OLE look into the registry for File Extension, Object Class ID, Object Prog ID, Interface ID or User and Machine Locale (the locale of the application needs to suit the user and machine locale setting). A general rule is to find an application whose locale matches the user's default locale, the machine's default locale, or the user's default Language. Also, as described above, each package is associated with a list of hardware architecture and operating systems on which it is supported on. The Directory Lookup matches the client machine's architecture and operating system in this list. Lastly, when the activation is for a certain file extension, (e.g., .XLS) and the Directory has more than one published application that can service that file type, then an administrator specified priority is used to pick the most preferred one. In addition to applications, the COM libraries 82, Shell 84 and Internet Explorer 86 automatically use the class store schema to install missing components. As generally represented in FIG. 7, if a requested (step 700) software implementation (e.g., object class) is available in the local registry (step 702), the system provides it (step 704). If not found, however, the system instead looks in the class stores (step 706) for a suitable implementation and returns it if found (step 708). As can be seen from the foregoing detailed description, there is provided a class store schema that provides centralized information to administer a network. The schema enables the management and deployment of applications, components and services across a computer network. While the invention is susceptible to various modifications and alternative constructions, a certain illustrated embodiment thereof is shown in the drawings and has been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||
