Back-end decoupled management model and management system utilizing same6871346Abstract Presented is a web-based enterprise management compliant management framework whose back end components are decoupled from the various user interfaces available for accessing the management system. In the Windows environment, the management system of the instant invention is also compliant with the Windows management instrumentation (WMI) requirements. This management system includes WMI providers which implement standard interfaces which decouple all semantic and syntactic checks from the user interface and which provide common error strings, help, etc. to a user regardless of the user interface being used. The providers of the management system of the instant invention store and access data in the active directory. As such, these providers present a customizable user interface which may be based on a user's expertise level and which may be dynamically localized to the user's preferred language. Transaction support is also provided which prevents multiple users from changing the same attributes at the same time through different user interfaces. Claims We claim: Description This invention relates generally to enterprise management models and, more particularly, relates to a Management model that enables a consistent system behavior regardless of what type of client is used to manage the system.
Description This method will be used to set a value to an
attribute
Signature HRESULT Set ( [in] string attributeName,
[in] VARIANT *pvValue).
Input Parameters attributeName - is the name of the attribute whose
value needs to be set pvValue - is the value that the
attribute needs to be set to
Output Parameters None
Return Value S_OK - Success
E_POINTER - Null Pointer specified
E_INVALIDARG - Invalid Argument
E_OUTOFMEMORY - Out of Memory
Description This method will be used to retrieve the value of
an attribute
Signature HRESULT Get ( [in] string attributeName,
[out] VARIANT *pvValue);
Input Parameters attributeName - is the name of the attribute whose
value needs to be retrieved
Output Parameters pvValue - the retrieved value of the attribute
Return Value S_OK - Success
E_POINTER - Null Pointer specified
E_INVALIDARG - Invalid Argument
E_OUTOFMEMORY - Out of Memory
Description This method will be used to get the default value of
the attribute (if any).
Signature HRESULT GetDefaultValue ( [in] string
attributeName, [out] VARIANT *pvValue);
Input Parameters attributeName - is the name of the attribute whose
default value needs to be retrieved
Output Parameters pvValue - the retrieved value of the attribute
Return Value S_OK - Success
E_POINTER - Null Pointer specified
E_INVALIDARG - Invalid Argument
E_OUTOFMEMORY - Out of Memory
Description This method will be used to get the list of valid
values of the attribute. This can be used to show a
list of values that the user can select from. This will
eliminate the overhead of dealing with invalid en-
tries that can result in expensive network roundtrips.
Signature HRESULT GetValidValues ( [in] string
attributeName, [out] VARIANT *pvValue[ ]);
Input Parameters attributeName - is the name of the attribute whose
valid values needs to be retrieved
Output Parameters pvValue - an array of valid values for the attribute
Return Value S_OK - Success
E_POINTER - Null Pointer specified
E_INVALIDARG - Invalid Argument
E_OUTOFMEMORY - Out of Memory
Description This method will be used to get validation rules for
the attribute (if any). The rules can have information
on dependency on other attribute values.
For example, if attribute A is set to value V, then
attribute B has to be set to a non-zero value.
Signature HRESULT GetValidValues ( [in] string
attributeName, [out] ValidationRule
*pValidation [ ]);
Input Parameters attributeName is the name of the attribute whose
validation rules needs to be retrieved
Output Parameters pValidation - an array of validation rules
for the attribute
Return Value S_OK - Success
E_POINTER - Null Pointer specified
E_INVALIDARG - Invalid Argument
E_OUTOFMEMORY - Out of Memory
Description This method will be used to get information about
an attribute or method.
If it is an attribute, then it can include a short
description of the attribute,
type information, Range of values (if any) etc.
If it is a Method then it can include information for
usage, input parameters, output parameters,
return value etc.
This will be used to display information about the
attribute on the UI.
Signature HRESULT Help ( [in] string
attributeOrMethodName, [out] string *pHelp);
Input Parameters attributeOrMethodName - is the name of
the attribute
Output Parameters pHelp - the localized help string
Return Value S_OK - Success
E_POINTER - Null Pointer specified
E_INVALIDARG - Invalid Argument
Description This method will be used to save the Resource
object to a persistent store. This will be used
when the user needs to save the system
configuration to a persistent store. The system wide
Save method will in turn call the Save method
on each resource instance.
Signature HRESULT Save ( [out] Object *pInst);
Input Parameters None
Output Parameters pInst - the instance of the Resource to be persisted
Return Value S_OK - Success
E_OUTOFMEMORY - Out of Memory
Description This method will be used to restore the Resource
object from a persistent store. This will be used
when the user needs to restore the system
configuration from a persistent store. The system
wide Restore method will in turn call the Restore
method on each resource instance.
Signature HRESULT Restore ( [in] Object *pInst);
Input Parameters pInst - the instance of the Resource to be restored.
Output Parameters None
Return Value S_OK - Success
E_POINTER - Null Pointer specified
E_OUTOFMEMORY - Out of Memory
Under the management system of the instant invention, the process of creating a Resource involves several steps as conceptually illustrated in FIG. 8. First, the user selects a particular element 142 on the Web interface, which has a corresponding WMI Class. The UI component then requests the definition of the class from WMI using IWbemServices::GetObject( ) 144. WMI next identifies the appropriate Resource Provider and invokes IWbemServices::GetObject( ). Then the Resource Provider returns 146 the class definition to WMI, which in turn returns it to the UT component. Once the class definition is obtained, the UI component calls IWbemServices::PutInstance( ) 148, which results in WMI invoking the same method on the Resource Provider, which will create the instance and persists it. As an example of how the Resource Provider is implemented in an exemplary embodiment of the instant invention, the following will demonstrate the implementation of a Routing Rule in the exemplary implementation of the management system of the instant invention as illustrated in FIG. 9. In a telephony system, the Routing Rule determines which Trunk Group to use depending on the dial prefix employed. Therefore, there are two attributes associated with a Routing Rule, the Dial-prefix and Trunk Group. The MOF (Managed Object Format) file holds the definition of the class as follows:
[dynamic,
provider("VA_RoutingRuleProv")
]
class VA_RoutingRule
{
[key] string GUID;
string routeRuleName;
string dialprefix;
VA_TrunkGroup ref refTrunkGroup;
//methods
uint32 Set ( [IN] string attributeName, [IN] VARIANT *pvValue);
uint32 Get ( [in] string attributeName, [out] VARIANT *pvValue);
uint32 Help ( [in] string attributeOrMethodName, [out] string *pHelp);
uint32 Save ( [out] Object *pInst);
uint32 Restore ( [in] Object *pInst);
};
In this example, the qualifier `dynamic` indicates to WMI that the provider should be used to generate instances. The provider qualifier identifies the name of the provider that is associated with this class. Note that every class should have a key attribute. This attribute is used to identify an instance uniquely (similar to a key in a database). Since GUIDs are unique, they can be used as the key values. The Trunk Group associated with the routing rule is represented by another resource. Accordingly, an instance of VA_RoutingRule will hold a reference to an instance of the trunk group. The MOF file for the provider 150 of this Resource is defined as follows in this exemplary embodiment;
instance of_Win32Provider as $P
{
Name="VA_RoutingRuleProv";
CLSID = "{7D37ACC6-30CC-11d3-BF3E-005004602632}";
};
instance of_InstanceProviderRegistration
{
Provider = $P;
SupportsGet = TRUE;
SupportsEnumeration = TRUE;
QuerySupportLevels = { "WQL:UnarySelect" };
};
instance of_MethodProviderRegistration
{
Provider = $P;
};
The CLSID represents the COM server that implements the provider 150. The instances of.sub.-- _InstanceProviderRegistration and _MethodProviderRegistration inform WMI 106 that this provider 150 is capable of generating instances and executing methods for the class VA_RoutingRule. Once this is complete, a COM server (either InProc or EXE) is defined and all the required interfaces are implemented. Finally, this server is registered with COM with the CLSID in the MOF file. WMI uses the CLSID to load the correct provider when a client application requests an instance of this class. To retrieve instances of this class VARoutingRule, the class definition must be retrieved and then the instances must be enumerated. In addition to this, the security impersonation level must be set so that WMI will be able to make calls to their interface pointers. In an exemplary embodiment, the ASP script for this is as follows:
<%@ LANGUAGE="VBSCRlPT"%>
<HTML>
<HEAD>
<TITLE>Enumerate Route Rules</TITLE>
</HEAD>
<BODY>
<%
on error resume next
Set Locator = CreateObject("WbemScripting.SWbemLocator")
Set Service = locator.connectserver
ifErr = 0 then
%>Connected to WMI!
<%else%>
Sorry, Did not connect.
<%if Err = 0 then
`Retrieve the class`
Set RoutingRule = Service.Get ("VA_RoutingRule")
Set Routes = RoutingRule.Instances.sub.--
`Set impersonation level
`to use credentials of caller
Routes.Security_.impersonationLevel = 3
for each RoutingRuleInstance in Routes%>
<%
Next
%>
</BODY>
</HTML>
When using Scripting to access WMI, there are some security issues involved as will be recognized by one skilled in the art. If the DCOM impersonation level is not set to the correct level, then the provider may not be able to get the information that the client (script) is requesting. There are four levels of impersonation that can be set in DCOM. The first level hides the credentials of the caller. Calls to WMI may fail with this impersonation level under the system of the instant invention. The second level allows the objects to query the credentials of the user, however, calls to WMI may also fail with this impersonation level. The third level allows the objects to use the credentials of the user, and is the recommended impersonation level under the management system of the instant invention. The fourth level allows objects to permit other objects (delegate) to use the credentials of the caller. As this may present a security risk, it is not recommended. As will be apparent to one skilled in the art from the foregoing, a significant advantage is provided by the management framework of the instant invention by decoupling the back end components from the user interface. In this way, a user of the management framework will experience the same consistent behavior regardless of which user interface is being used. This consistent behavior will provide the same checks, help, error strings, etc. Additionally, the management framework of the instant invention allows the flexibility of adding new user interfaces without the necessity of changing the back end components. This advantage is provided through the WMI framework which provides a COM based object manager model. In this way, any interface that can talk to a COM server can talk to the management model of the instant invention. By providing a standard set of interfaces for the WMI providers of the instant invention, consistent enterprise management may be accomplished from any type of user interface. As an example with reference to FIG. 9, if a user desires to set the value of an attribute of one of the managed elements of the enterprise system utilizing NetShell, the user would simply invoke the standard interface "set" method designating the name and value of the attribute to be set. NetShell simply inputs the value and CIMOM calls the provider "set" method. NetShell no longer cares what the value is since all checks of the value are done by the set interface by the provider. The provider then returns a localized error string which NetShell then displays to the user. This performance is the same whether MMC or a web-based user interface are utilized to set the value of the attribute. To change the value or the behavior of the user interface in the system of the instant invention, one only need to modify the provider itself without concern for any other changes anywhere else in the system. This is accomplished because every component has knowledge of the management data and is self-contained. The standard interfaces of the instant invention perform the necessary work without the client process having knowledge of the component's data. As an example of the benefit provided by the above-described standard interfaces, the following is an exemplary discussion of the configuration of an enterprise telephony server. As will be recognized by one skilled in the art, an enterprise's telephony server will include many attributes, some of which are liable to be quite complex, which all must be set in order to allow operation of the telephony system. Unfortunately, many smaller enterprises do not employ individuals which have sufficient knowledge or the resources to configure such a large and complex system. Utilizing the management framework of the instant invention, a configuration of the entire telephony system may be implemented at the telephony vendor location based upon the requirements of the enterprise. This configuration may then be provided to the enterprise on a disk or via other media so that it can be uploaded to their particular installation through the restore configuration interface. Such was not available in the prior systems. Such a save and restore configuration interface is made possible because every component provider knows what it needs to persist, what it will need to upload, where it wants to persist, how it wants to persist, etc. In other words, every component provider has the knowledge of what data it needs to save, how it wants to save that information, and how to upload that information to restore an operable configuration to the system. With as many providers as are required in a typical enterprise system, these standard interfaces defined by the instant invention become the basic building blocks of enterprise system management. Further, the management framework of the instant invention also includes transaction support to ensure that the restore configuration interface succeeds in all aspects necessary for task completion. That is to say, if a configuration has many operations which must successfully be completed for a configuration to be complete, the failure of any one operation will allow rollback capability to alert the user of the failure of one of these operations so that the problem may be corrected and the configuration completed. Further, since multiple user interfaces are available, it is conceivable that multiple users may attempt to manage the same component at the same time through different user interfaces. To prevent such an occurrence from leading to unknown system configuration, a common point is instituted in the providers to ensure that only one operation is being attempted on a particular service or feature at any given point. If the provider is busy with another operation, a message informing the user is generated. This transaction support is possible since all attributes for each component are data driven, that is there are no static pages at the UI level to be updated. The system of the instant invention also provides a customizable user interface which may be based, for example, on the expertise level associated with each particular user. Once the user has been authenticated through appropriate means, the provider then uses the Active Directory which has information about all of the users to retrieve an expertise level so that the provider knows what type of user interface to provide. Based on this expertise level, the provider may not show certain help features if it is determined that the user is a knowledgeable user, or may show additional help for each attribute on different pages for novice users. This expertise level may be changed as appropriate so that nuisance help messages to a more experienced user are not displayed. In addition, dynamic localization is provided by the management framework of the instant invention. This localization may be based upon user setting-sin the Active Directory, or more preferably based upon the browser language settings of the web UI. By utilizing dynamic localization based upon the language settings, the user experience is made more pleasant, simpler, and more cost effective. Unlike many web sites which provide separately addressed pages for different languages, the dynamic location of the instant invention is accomplished through the back end provider based upon the language settings. As such, a user may access the same addressed locations and receive different language pages based solely on the language setting of the user's browser. With an understanding of the implementing of the Management Resources now firmly in hand, attention is turned to the implementing of Management Tasks under the management system of the instant invention. Management Tasks can be defined as software components that provide a specialized functionality to execute certain management related operations. These operations will usually result in some kind of interaction with management components, and are modeled using WMI methods. As with management resources, there are two steps involved in exposing Management Tasks. The first is to define the UI Components. This comprises the UI components needed to expose the Task on a web page/browser and to access the resource via CLI. The second is to implement the Resource Providers. This consists of a WMI Provider that provides the Methods associated with the Task. As in the case of Resources, the Task's UI components are stored in the UI Framework. The difference is that there is only an ObjectClass associated with the Task, as the actual instance on which the method has to be invoked will be determined at run time. Therefore, the Web page element's attributes comprises the WMI class name that models the Task (ObjectClass), the URL Path of the ASP page that is launched when this Web element is selected (URL Path), the File Name of the ASP Page (ASP Page), and the icon associated with this element (Graphic). The ASP scripts have the User Interface Components as well as the code to interact with the Task Providers. The CLI components are similar to implementing CLI components for Management Resources as discussed above. The Task Providers implement all the necessary functionalities that are required to implement a Management Task. They are implemented as WMI Method providers, which in turn are COM servers and can be In-Proc DLLs or Out of Proc EXEs. To be a Method Provider, certain IWbemServices methods need to be implemented. For example, a method to be used to execute a method on the resource needs to be implemented. As an example, the code segment for this method may appear as follows: HRESULT ExecMethod([in]const BSTR strClass, [in] const BSTR strMethod, long IFlags, IWbemContext pCtx, IWbemClassObject*pInParams, IWbemClassObject*pOutParams, IWbemCallResult**ppCallResult), where: strClass--object path to the class that contains the method strMethod--is the name of the method IFlags--flag. If set to zero, it will execute synchronously pCtx--pointer to context, typically NULL pInParams--pointer to Input parameters. NULL if there are no input parameters pOutParams--pointer to Output parameters. NULL if there are no output parameters ppCallResult--will contain the result. If NULL on entry, this is not used. All Task Providers should implement the following method:
Description This method will be used to get information about a
method. It can include information for usage, input
parameters, output parameters, return value etc.
Signature HRESULT Help ( [in] string methodName,
[out] string *pHelp;
Input Parameters methodName - is the name of the attribute
Output Parameters pHelp - the localized help string
Return Value S_OK - Success
E_POINTER - Null Pointer specified
E_INVALIDARG - Invalid Argument
To aid with an understanding of the instant invention, attention is returned to the example of the Route Rule discussed above. If, in this example, the system requires the association of a Task "Add a Route Rule" that will be used to create a new Routing Rule, then an exemplary embodiment of the class definition, in a MOF (Managed Object Format) file, holds the definition of the class as follows:
[dynamic,
provider("VA_RoutingRuleTaskProv")
]
class RouteRuleTaskProv
{
Static: uint32 Add([IN] string RouteRuleName,[IN] string DialString,
[IN] VA_TrunkGroup refTrunkGroup);
Static: uint32 Help ( [in] string methodName, [out] string *pHelp);
}
The MOF file for the provider of this Task will be defined as follows:
instance of_Win32Provider as $P
{
Name="VA_RoutingRuleTaskProv";
CLSID = "{7D37ACC6-30CC-11d3-BF3E-005004602633}";
}
instance of_MethodProviderRegistration
{
Provider = $P;
};
Preferably, the Management Tasks will be implemented as wizards in the Web User Interface As such, the user is guided through a series of steps that will accomplish the management operation. These wizards can be customized in different ways, including according to the configuration of the system. Depending on the hardware and software components that are installed on a particular enterprise telephony system, the wizard is automatically customized to show only those steps that are relevant to the configuration. For example, if a new User is being added using the Add User wizard, one of the steps in the wizard will be configuring the RAS properties for the user. However, if the system is not configured to be a RAS server or there are no RAS capable devices installed, then this step will not be shown to the user. The wizard may also be customized according to the expertise level of the user. After the administrator has used the wizards for some time, he/she may not want to go through all of the steps. In this case, all the steps can be combined into a single step to make the task execution faster. The expertise level is preferably a user attribute that can be set when the user is created in the system. As introduced above, the management framework of the instant invention utilizes object-oriented schema. A schema defines a set of objects that can be created and the attributes that can be used to describe those objects. The definition of an object in the schema, commonly called a class, will contain a list of attributes that an instance of a class must have to be stored in the directory, a list of attributes that an instance of a class may have to be stored in the directory, a list of classes that can be parents of the instances of the class, and a list of classes from which the class is derived. In the exemplary embodiment of a telephony system, the telephony management classes (TMCs) are derived from either X.500 classes or the CIM classes. X.500 provides classes such as Top, which is the root class for the directory, and OrganizationalPerson, which is used to define the concept of person in an organization. Active Directory (AD) schema has a class "User" that is derived from OrganizationalPerson. For the system of the instant invention, an Auxiliary class is defined that contains additional attributes to model the telephony user. On the other hand, CIM provides classes such as LogicalElement, which is used to represent elements that are used to realize one or more Logical elements. This class is derived from ManagedSystemElement. Examples for a telephony system include Trunk Groups, Route Rules, Dial Plan, etc. A second class provided by CIM is PhysicalElement. This class is used to represent elements that have a distinct physical entity. This class is also derived from ManagedSystemElement. Examples in the exemplary telephony system include Extensions, Trunks, etc. The Active Directory (AD) is preferably used as the storage mechanism for the management information utilized in the instant invention. This is because AD is reliable, replicable, secure, and distributed. Active Directory is included with the Windows 2000 operating system. It extends the features of the previous Directory services and adds new features to it. One of the key advantages of integrating with AD is that there is a unified User Database. In traditional PBX systems, there was no relation between the user's attributes as stored on the PBX and other systems such as email or file security. This meant that the same user had to be added to multiple databases and often by different administrators, which could result in inconsistent information. The management system of the instant invention eliminates this overhead of having multiple user databases. The second advantage of AD is the ability to define User Policies that determine the services a User or Group can access. This can be quite handy for administrators to be able to apply policies to a set of users and be able to modify policies as required. For example, consider Company X has two types of employees, namely Full Time and Contractors. Every user in the system will belong to one of these groups. Policies that define access to various services will be in place for each group. If the company has a policy that only Full Time employees can make outbound international calls, then this attribute can be set to `true` in the Full Time Employees Group policy, automatically giving access to this service for all users in this group. If there is a special case, such as if a particular Contractor needs to be given this permission, then the user policy for this particular user can be modified to reflect this change. Since the user's policy will override the Group's policy, the user will gain access to this service. However, the Group policy will still apply to the remaining users in the group. A third advantage of using AD is security. AD allows security to be defined at the object and at the attribute level. Access Control Lists (ACL) protect all objects in the Active Directory. ACLs determine the type of access to an object depending on which user is trying to access it. ACL is a list of Access Control Elements (ACE). Each ACE contains a Security descriptor that identifies the User or group to which it applies and the type of access. ACEs can apply to objects or attributes, which gives a very fine grained control to the administrator of not only what objects a user can see or modify, but also which attributes in the object can be seen or modified. Active Directory Services Interfaces (ADSI) provides a rich set of COM interfaces that can be used to browse or extend the schema, add objects and modify attributes in the Active Directory. The Resource and Task Providers can use these interfaces to access the ADS. ADSI solves the problem for customers who have multiple directories and multiple interfaces to deal with. It can be compared to ODBC. ODBC provides open interfaces for relational databases, thus allowing developers to write applications and tools that will work with any database that supports ODBC. Because of the thriving ODBC development community, every major relational database now supports ODBC. ADSI is "ODBC for directory services." To use Active Directory as the storage mechanism, the schema has to be extended to represent the managed elements for the exemplary telephony system of the instant invention. The schema is extended using the Active Directory Schema Manager snap-in. The management data is updated and accessed using Lightweight Directory Access Protocol (LDAP). Active Directory in Windows 2000 is compliant with LDAP 3.0, and the LDAP API can be used to access data in Active Directory. ADSI provides uniform, object-oriented access to multiple directories, and supports directory access in Windows 2000, Windows NT 4.0 and Novell Netware Directory Services (NDS). The LDAP Provider is used to access AD in Windows 2000 environment. Since ADSI provides COM based interfaces, it can be accessed using high-level languages like C/C++ or scriptable languages like Visual Basic. In the telephony scenario of the exemplary embodiment of the instant invention, Resource and Task providers will access ADSI. Since these providers are written using C++, the following discussion will be confined to such language, although one skilled in the art will recognize that such discussion is for purposes of illustration only, and is not limited solely thereto. For schema management, the Active Directory Schema Manager allows schema administrators to extend the schema by creating and modifying classes and attributes. The schema manager is a MMC snap-in. There are some prerequisites that have to be met in order to change the AD schema. For security reasons, schema management is restricted to a group of users called schema administrators. Only those users logged in as a member of schema administrators group can perform schema management. Further, schema operations are restricted to support only one master, which means that only one domain controller can modify the schema at any given time. This is called Floating Single Master Operations (FSMO) and is described in detail in a co-pending application entitled "Floating Single Master Operation", filed an on Sep. 21, 1998 as application Ser. No. 09/157,774. The schema FSMO can be transferred from one server to another by simply right clicking on the root of the schema manager and selecting "Change Domain Controller." The dialog-box that pops up can be used to change the FSMO. To allow a domain controller to change the schema, a registry entry has to be added. The key is "Schema Update Allowed" and its value is of type DWORD. This has to be set to a non-zero value to allow schema updates. The Schema Manager can also be used to create new attributes. Right clicking on the "Attributes" node, brings up a menu from which selecting "sew" pops up the New Attribute Dialog box. The common name, LDAP name and Object Identifier for the attribute has to be specified. Object Identifiers (OID) are issued by Standards bodies such as ITU, which the organization has to obtain for their use. In addition to schema, new classes may also be created. Classes can be of different types namely Structural, Abstract and Auxiliary. However, the structural class is the only class from which AD objects can be created. The created classes can be derived from Structural or Abstract classes, and can have Auxiliary classes associated with it. Abstract classes are similar to abstract classes in C++, and serve as templates that can be used to create other classes. Auxiliary class is used to extend a structural class and comprises a list of attributes that can be associated with one or more structural classes. To access the AD, one has to find the domain controller and bind to the object in the directory. In ADSI, the directory object is represented as a COM object, which means that the binding requires that a COM interface be specified. All ADSI COM objects that represent directory objects have an IADs interface. It will also have other interfaces depending on the type of the object. For example, a user object has a IADsUser interface in addition to the IADs interface. To bind to a directory object, either ADsGetObject or ADsOpenObject can be used, the difference being the Get operation uses the currently logged on user's credentials whereas the Open operation allows a specific user's credentials to be supplied. It is recommended to use the logged on user's credentials. If the data exchange between the provider and AD needs to be encrypted to protect it over the network, then the Open operation should be used. If NULL is specified for user and password, then the Open operation uses the current logged on user's credentials. The server name should not be hard coded when binding to the directory. AD supports serverless binding which means that the server name need not be specified when accessing AD of the logged-on user's domain. When processing the "bind" call, ADSI finds the "best" Windows 2000 Domain controller in the domain of the user currently logged on. In LDAP 3.0, rootDSE is defined as the root of the directory information in the directory server. The rootDSE provides information about the directory server. ADsPath string for rootDSE is LDAP://rootDSE or LDAP://servername/rootDSE. The first option is used when doing serverless binding. rootDSE is a well-known and reliable location on every directory server to get DNs to the domain container, schema container, configuration container and other information. It has information about the directory server, and it preferably includes the following information:
Property Description
namingContexts Multi-valued. Distinguished Names (DN)
for all naming contexts stored on this
directory.
DefaultNamingContext By default, the DN for the domain of
which this directory server is a member
SchemaNamingContext DN of the schema container
ConfigurationNamingContext DN for the configuration container
DnsHostName DNS address of the directory server
All ADSI COM objects have one or more interfaces with methods that retrieve the properties of the directory object they represent, including a specific property by name, a list of properties, enumerate all properties on the object, and to get special properties. Specifically, IADs::Get is used to get the value of a single valued attribute and IADs::GetEx is used to get the value of a multi-valued attribute. IDirectoryObject::GetObjectAttributes is used to specify a list of attributes to get. It returns an array of structures that contain the values of the requested attributes. Further, the IADsPropertyList interface has methods to enumerate the properties, and the IADs interface has methods to get some special properties that are not stored in the object. IADs also has methods to get values in a data format that is different from the format that is stored. Setting properties is similar to getting properties. However, when setting a property, the value is only written to the local property cache on the client machine until the SetInfo method is called. This allows the properties to be written to local cache and uses SetInfo only when the data is in a consistent state. As with getting properties, setting properties may be used to set a specific property by name and to save the current value of the property. Specifically, IADs::Put is used to set the value of a single valued attribute to the local cache and IADs::PutEx is used to set the values of a multi-valued attribute to the local cache. Further, IADs:SetInfo is used to save the current value of the property from the property cache to the underlying directory store. SetInfo will update objects that already exist or create a new directory entry for newly created objects. As introduced briefly above, there are a number of security issues that are involved when accessing WMI and the management data. It is important that the calls to ADSI to retrieve management data from Resource and Task Providers are done using the client user's credentials so that the correct security is enforced. In the enterprise telephony management scenario of the instant invention, there are two types of clients that can access management data. They include Web UI using ASP/IIS and CLI using NetShell. User authentication can be done using Windows integrated authentication using NTLM or Kerberos. Kerberos authentication allows delegation to be used to transfer impersonation credentials over more than one cross-host hop. This is useful if IE, IIS and WMI are running on different hosts. If at least two of them are running on the same machine, then NTLM can be used. As will be understood by one skilled in the art, a privilege is the right of an account, such as a user or group account, to perform various system-related operations on the local computer, such as shutting down the system, loading device drivers, or changing the system time. Each Windows 2000 user has a list of privileges defined against the account. When the user is authenticated, an access token is created that reflects the privileges of the user. When a system operation is attempted, then the user's privileges are checked to verify the privileges. The operation is allowed only if the privilege is enabled. For DCOM in Windows 2000, the concept of cloaking has been introduced. When this is enabled on the proxy, privilege settings on the current thread are marshaled to the server at the point of invocation of the call on the remote proxy. This allows privileges to be scoped for each operation by setting them before an operation and resetting them after an operation. The DCOM authentication level determines when security checks are made. There are different levels of authentication that can be used as follows:
Authentication
Level Security Level
None No authentication and the least amount of security.
Default The level of security is set to Authentication Service.
Connect Authenticate security on an initial connection to the
DCOM server.
Call Authenticate security on every call accepted by the
DCOM server.
Packet Authenticate all data with the sender's identity.
Packet Integrity The sender's identity and signature are encrypted to
ensure the authenticity of the sender and to ensure that
packets haven't been changed during transit.
Packet Privacy The sender's identity and the data are encrypted to
ensure maximum security.
The DCOM impersonation level allows the server to use the client's permissions when making calls. This will ensure that the client's access permissions are used to access system data. There are different levels of impersonation that can be used. For WMI, the recommended impersonation level is 3, which allows WMI to use the credentials of the user. This means the credentials of the user is passed to the provider for operations on Active Directory. In a preferred embodiment of the instant invention, two levels of diagnostics will be available. High-level diagnostics can include things like restarting trunks, getting status of extensions etc. This will be available through the enterprise telephony management console with Web UI and CLI. Low-level diagnostics can include real time monitoring of trunks for timing/framing errors, monitor data flow for debugging extensions, etc. These low-level diagnostics will be available from separate applications which will be supplied by the respective hardware vendors. In general, the management system of the instant invention, in a preferred application to an enterprise telephony system, will include alarms that will signal when a component is faulty. These alarms can be reported in different ways, including indication on web UI, via dial out modem on a out of band card, an SNMP alert (out of band), via pager, e-mail, or via NT Eventlog. The system also includes logging to text files with different levels of detail, as well as a change log to indicate changes made to the system configuration and by whom. The system of the instant invention also restarts components when faulty, and includes a watchdog timer for monitoring system resource usage (media resources like ASR/TTS), status of components, restarting faulty components, etc. Out of band control using special boards is also included, as is online help that will give easy access to technical manuals for various boards and hardware. Specifically for trunks, the system of the instant invention provides high-level diagnostics which include alarms that signal when a trunk is faulty. The system may also seize individual trunks for listen-in (to check status or detect toll-fraud) and dialing out. Preferably, the operator can listen-in on idle trunks and the administrators can listen-in on active calls. The status of all trunks may also be displayed on the Web UI (with color codes). Logging with different levels is also available to trace calls in a preferred embodiment. Further, the system includes the ability to get physical location of a trunk such as which board it is connected to, etc., as well as the ability to restart individual trunks when faulty. The low-level diagnostics for the trunks include real time call tracing in GUI and file for debugging, and real time data flow monitoring for framing/timing errors. With regard to extensions, the high-level diagnostics provided include alerts when an extension is faulty, and the ability to remotely control extension for testing. Further, the status of all extensions on web UI (with color codes) is provided, as is the ability to get the physical location of an extension, such as the board to which it is connected, etc. The low-level diagnostics include real time call tracing for debugging and real time data flow monitoring. Another aspect of the system of the instant invention is its ability to localize. The Web User Interface will be localized to support different languages. Specifically, the ASP Pages that make the UI components are localized for the various languages. So, each ASP page will have a localized version in every language supported. These ASP Pages will have the same file names and will be stored in a separate directory for each language. For example, if the server name is "Telephony" and all the ASP pages are stored under the IIS virtual directory ManagementScripts, then each language will have a sub-directory under this directory. Therefore, all English ASP Pages will be stored under ManagementScripts/en, all German ASP Pages will be stored under the ManagementScripts/de, etc. The localization is done on a per session basis. In ASP, a new session starts when the user requests a URL that identifies an ASP page in the application. A globala.asa file has to be defined which will have procedures defined for the session management. The language for the session is determined by the browser's language setting that is sent to the server along with other information when it makes a request to the server. This language setting is determined by using the HTTP header information. The user is then redirected to the ASP page for that language using the Redirect method. The start page for the language is different for the management console according to the language setting of the browser. This way, every user can dynamically localize their session with the Management console according to their choice of language, simply by changing the language setting on the browser. With this understanding of the operation of the system of the instant invention, attention is now focused on the managed components of the system. The enterprise telephony system in which the management framework of the instant invention is exemplary embodied is communications server that provides both data and voice related services. As such, the components that need to be managed by the system of the instant invention include users, extensions, dial plans, trunks, trunk groups, supplementary services, call logging, call routing, remote access service (RAS) server, router, dynamic host configuration protocol (DHCP) server, DNS server, and proxy server. Each of these managed components will be addressed in turn below. The Active Directory Schema has a "User" class that represents a User in the Windows environment. In the enterprise telephony domain, some attributes are added to this User class. These attributes are part of an Auxiliary class "Telephony User" which will be an extension to the User class. The prefix ms-Tel will be used for the class and attribute names, and the LDAP names will be the same as Common Names, except that they will not contain hyphens. An example of this TelephonyUser class follows:
Common-Name ms-Tel-TelephonyUser
Class Type Auxiliary Class
Subclass of Top
Admin Description Auxiliary class for Telephony User
Now, attributes that will extend the "User" class to hold information that will be relevant to a user in the enterprise telephony system will be added using a naming convention for these attributes as follows:
Attribute Type Description
ms-Tel-DirectoryNumber String Main number for user
ms-Tel-AdditionalNumbers Array of Additional numbers for
Strings user
ms-Tel-VoiceMailNumber String The voice mail number
ms-Tel-VoiceMailPassword String The password used when
accessing voice mail
ms-Tel-CallForwardOnBusy String The number the call
should be forwarded to
when the user's
extension is busy
ms-Tel-CallForwardOnNoAnswer String The number the call
should be forwarded to
when the user doesn't
answer the call
ms-Tel-CallForwadImmediate String The number all calls are
forwarded to
ms-Tel-ClassOfService Object Provisioning for various
telephony features
ms-Tel-CallPickupGroup Object Call pickup group to
which the user belongs
ms-Tel-ExpertiseLevel Enum Determines the expertise
level of user and can be
one of the following
Novice
Expert
The various tasks associated with User Management and the corresponding actions that need to be taken are as follows:
Task Task Description
Add a User Add a new user
Delete a User Remove an existing user
Edit User's Profile Edit an existing user's profile
Save User's Profile Save User profile to a persistent store
Restore User Profile Restore User Profile from a persistent store
Enable RAS access Used to give a user RAS permissions
for user or group
Configure RAS Used to specify RAS properties for user that can
properties for user include Verify Caller ID or
or group Enable callback
Static IP address (if any)
Static route (if any)
Configure User Used to specify Telephone properties for user that
Telephone can include Extension number
properties Type (Analog, IP etc)
Voice Mail number
Call Forwarding info
Configure Proxy Enable users or groups of users to access internet.
permissions for
user or group
Configure Max- Used to specify the maximum size of a mailbox
imum Mailbox size
for user or group
Configure Class Used to specify the Class of service attributes for
of Service the user
Under the system of the instant invention, the processes of adding a User requires that the Class User is obtained, an instance of User is created, the values of the attributes are set, and the instance is saved. The second type of component is an Extension. Extensions can be of many types ranging from an Analog Telephone to an IP Phone. Depending on the type of extension, some attributes may be relevant and some may be not. Since Extensions are physical elements, a class is derived from class Physical-Element as follows:
Class Telephony-Extension
Type Structural Class
Subclass of Physical-Element
Auxiliary-Classes
The Extension's attributes include the following:
Attribute Type Description
Manufacturer String Name of the manufacturer
Directory Number String The Directory Number of the extension
Type Enum Type of extension can include Analog,
Digital, IP etc
Gatekeeper Address String Gatekeeper to be used (for IP phones)
Board Address String Will include board address and position
(for analog & digital phones)
The tasks associated with Extensions include the following:
Task Description
Add an Extension Used to create a new extension and the following
needs to be specified
Name
Directory Number
Type (Analog, ISDN, IP, etc)
Board and position (in case of Analog or
digital phones)
Gatekeeper address (in case of IP phones)
Remove an extension To delete an extension
Edit an extension To edit the attributes of an extension
The dial plan is the brains of the call routing system. Based solely on the digits in the dialing string, the dial plan can make intelligent decisions as to where the call should be delivered. Dial Plans are logical elements. Therefore, a class is derived from CIM class Logical-Element as follows:
Class Telephony-DialPlan
Type Structural Class
Subclass of Logical-Element
Auxiliary Classes
The Dial Plan attributes include the following:
Attribute Type Description
Name String The name of this dial plan in the system
Y Integer A variable that can be assigned digits 0 or 1
N Integer A variable that can be assigned digits 2-9
X Integer A variable that can be assigned digits 0-9
Termination Character Terminating Digit
Digit
Pause Digit Character Pause Digit
DN String Directory Number
NPA String Number Plan Area
N11 String Service Access Codes (SAC)
NsN String National Significant Number 9-15 digits
CAC String Carrier Access Codes (10XXX, 101XXX)
CC String Country Code (1-4 digits in length)
CTY String City Code (1-2 digits in length)
AUTH String Authorization Codes (1-10 digits in length)
LEC String Account Codes (1-10 digits in length)
Pattern ID Registered patterns
(+n Instances)
The tasks associated with Dial Plans and the corresponding action to be taken includes:
Task Description
List The Administration Application will have the ability to list all
dial plan entries currently configured in the system.
Query The Administration Application will have the ability to query the
system for configuration information for each dial plan entry in
the system.
Add The Administration Application will have the ability to add new
dial plan rules to the system. When adding a new dial plan entry,
the Administration Application will be able to set any and all of
the configuration parameters defined in the previous section.
Any new dial plan entry that is added to the system will be
useable immediately without requiring a restart.
Delete The Administration Application will have the ability to remove
or delete a dial plan entry from the system. Before removing the
dial plan entry from the system, the Administration Framework
must ensure that no other dial plan entries are dependent on the
entry being removed.
Modify The Administration Application will have the ability to modify
or update any or all of the dial plan configuration parameters
in the previous section. This modification should take place in
real time, without requiring a restart.
Trunks connect the telephony server to the public network, and can be of many types, such as Analog, ISDN, IP, etc. Since Trunks are physical elements, a class is derived from the CIM class Physical-Element, and its attributes are as follows:
Class Telephony-Trunk
Type Structural Class
Subclass of Physical-Element
Auxiliary Classes
Attribute Type Description
Name String Name of the trunk
Type Enum Type of trunk which can be one of the following
Analog
ISDN
IP
Board String Board to which the trunk is connected to
Address
The tasks associated with trunks include the following:
Task Description
Add a trunk Used to create a new trunk and the following needs to
be specified
Name
Board connected to
Channel number
Type (Analog, ISDN, IP etc)
Direction -- Specifies what types of calls are allowed
(Inbound, Outbound or both)
Remove a Trunk Delete an existing trunk
Edit a Trunk Edit Properties of existing trunk
Trunk Groups are logical components that are used to group a number of trunks together. A selection method can be defined that determines which trunk will be selected from the group. Trunk Groups are logical elements and, therefore, a class is defined from the CIM class Logical-Element and its attributes are as follows:
Class Telephony-TrunkGroup
Type Structural Class
Subclass of Logical-Element
Auxiliary Classes
Attribute Type Description
Name String The name of the trunk group as it appears in
the system. This name must be unique.
Trunks ID Each trunk group will contain multiple trunks.
(+n instances) Each trunk will be configured in the following
trunk configuration section. This field will
contain a list of previously configured trunks
that are contained by this trunk group.
Glare String Defines the action to be taken when glare
Disposition occurs.
Direction String Defines the trunk direction. (In, Out, 2-Way)
Selection String The method utilized by the trunk group to
Method select a trunk for the next outbound call. In
other words, when a route guide asks a trunk
group for a trunk, this method is used to
determine which trunk should be use. It could
select the next available trunk starting at the
first trunk or last trunk, etc. This is highly
dependent on the implementation of the
trunk group.
Default String Defines the display text for an outside caller if
Caller ID the call ID is blocked or unavailable.
The tasks associated with a Trunk Group are as follows:
Task Description
List The administration interface should have the ability to obtain a
list of all trunk groups in the system. Once a trunk group is
selected, any of the tasks below may be performed.
Query The administration interface should be able to obtain the
values for any and all attributes of a given trunk group.
Add The Administration Application will have the ability to add
new trunk groups to the system. When adding a new trunk
group, the Administration Application will be able to set any
and all of the configuration parameters defined in the previous
section. Any new trunk group that is added to the system will
be useable immediately without requiring a restart.
Delete The Administration Application will have the ability to
remove or delete a trunk group from the system. Before
removing the trunk group from the system, the Administration
Framework must ensure that no trunk resources are currently
utilizing the trunk group.
Modify The Administration Application will have the ability to
Attributes modify or update any or all of the trunk group configuration
parameters in the previous section. This modification should
take place in real time, without requiring a restart.
Attributes to be modified are:
ID
Name
Glare Disposition
Direction
Selection Method
Default Caller ID
Add Each Trunk Group contains a list of Trunks that are contained
Trunks in the group. The Administrator will be able to Add trunks
to the Trunk Group at any time.
Delete Each Trunk Group contains a list of Trunks that are contained
Trunks in the group. The Administrator will be able to Delete trunks
from the Trunk Group at any time. When deleting trunks from
a trunk group, the Admin Framework must ensure that the
trunk being deleted is not in use.
Route guides are a logical link between a dialing sequence and a trunk group, and is highly dependent on the call control system. The general idea is that a dialed number can be prefixed by a digit or sequence of digits. This digit(s) will be a signal to the call control mechanism to use a particular route guide and in turn use a trunk in the associated trunk group to originate the outbound call. Rou | ||||||