Кіріспе
Windows интерфейсі мониторинг және хабарландыру үшін
Windows interface for monitoring and notification
Windows басқару құралдары (WMI) Windows драйверлік моделіне енгізілген кеңейтімдер жиынтығынан тұрады, ол операциялық жүйе интерфейсін қамтамасыз етеді, оның арқылы құралдандырылған компоненттер ақпаратты және хабарламаларды жібереді. WMI – Microsoft компаниясының Distributed Management Task Force (DMTF) ұйымының Web Based Enterprise Management (WBEM) және Common Information Model (CIM) стандарттарын іске асыруы болып табылады. WMI скрипт тілдеріне (мысалы, VBScript немесе Windows PowerShell) Microsoft Windows жеке компьютерлерін және серверлерін жергілікті және қашықтықтан басқаруға мүмкіндік береді. WMI Windows 2000-ден Windows 11-ге дейінгі операциялық жүйелерге алдын ала орнатылған. Ол Windows NT және Windows 95-тен Windows 98-ге дейін жүктеу арқылы қолжетімді. Microsoft сонымен қатар WMI үшін Windows Management Instrumentation Command line (WMIC) деп аталатын командалық жол интерфейсін ұсынады. Дегенмен, WMIC Windows 10, 21H1 нұсқасынан бастап, Windows 11 және Windows Server 2022-де қолданылмайды.
Windows Management Instrumentation (WMI) consists of a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is Microsoft's implementation of the Web Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF). WMI allows scripting languages (such as VBScript or Windows' PowerShell) to manage Microsoft Windows personal computers and servers, both locally and remotely. WMI comes preinstalled in Windows 2000 through Windows 11 OSes. It is available as a download for Windows NT and Windows 95 to Windows 98. Microsoft also provides a command line interface to WMI called Windows Management Instrumentation Command line (WMIC). However, WMIC is deprecated starting with Windows 10, version 21H1, Windows 11 and Windows Server 2022.
WMI-нің мақсаты
WMI-нің мақсаты – басқару бағдарламалары арасында басқару ақпаратын бөлісуге мүмкіндік беретін, қоршаған ортаға тәуелсіз, эксклюзивті ерекшеліктер жиынтығын анықтау болып табылады. WMI Windows жүйесі үшін корпоративтік басқару стандарттарын және қолданыстағы басқару стандарттарымен, мысалы, Жұмыс үстелінің басқару интерфейсі (DMI) және SNMP сияқты технологиялармен үйлесімді жұмыс істейтін стандарттарды белгілейді. WMI бұл стандарттарды бірыңғай модельмен толықтырады. Бұл модель басқарылатын ортаны көрсетеді, оның арқылы кез келген дереккөзден алынған басқару деректеріне бірыңғай тәсілмен қол жеткізуге болады.
The purpose of WMI is to define a proprietary set of environment independent specifications which allow management information to be shared between management applications. WMI prescribes enterprise management standards and related technologies for Windows that work with existing management standards, such as Desktop Management Interface (DMI) and SNMP. WMI complements these other standards by providing a uniform model. This model represents the managed environment through which management data from any source can be accessed in a common way.
Ерекшеліктері
Бір немесе бірнеше WMI провайдерлерін жасауға дайын адам үшін WMI көптеген мүмкіндіктерді ұсынады. Ең маңызды артықшылықтары:
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Автоматтандыру интерфейстері: WMI пайдалануға дайын автоматтандыру интерфейстерінің жиынтығымен бірге келетіндіктен, WMI провайдері және оның кластар жиынтығы қолдайтын барлық басқару мүмкіндіктері дереу скрипттік қолдау алады. WMI класын жобалау және провайдерді жасаудан басқа, Microsoft әзірлеу және сынау командалары скрипт моделін жасау, тексеру немесе сынау қажеттілігінен босатылады, себебі ол WMI арқылы қолжетімді.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
.NET басқару интерфейстері: System.Management кеңестігі қолданыстағы COM/DCOM құбырларына сүйенгендіктен, жасалған WMI провайдері мен оның WMI кластар жиынтығы тілге қарамастан (мысалы, C#, VB.NET) барлық .NET қолданбалары үшін автоматты түрде қолжетімді болады. WMI класын жобалау және провайдерді жасаудан басқа, скрипттеу сияқты, Microsoft әзірлеу және сынау командалары .NET Framework-те жаңа кеңестікті қолдау үшін жаңа жиналымдарды жасауға, тексеруге және сынауға міндетті емес, себебі бұл қолдау WMI арқылы тегін қолжетімді.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
C/C++ COM/DCOM бағдарламалау интерфейстері: Windows-тағы көптеген компоненттер сияқты, COM/DCOM бағдарламашылары жасаған провайдерлерінің мүмкіндіктерін COM/DCOM интерфейстері деңгейінде пайдалана алады. Бұрынғы орталардағыдай (скрипттеу және .NET Framework), COM/DCOM тұтынушысына WMI COM интерфейстерінің стандартты жиынтығымен өзара әрекеттесу қажет, WMI провайдерінің мүмкіндіктерін және оның қолдау көрсетілетін WMI кластар жиынтығын пайдалану үшін. Барлық басқару ақпаратын жергілікті API-ден алу үшін WMI провайдерін әзірлеушіге алдын ала анықталған WMI COM интерфейстерінің жиынтығымен өзара әрекеттесу қажет. Бұл басқару ақпаратын WMI COM деңгейінде автоматты түрде қолжетімді етеді. Сонымен қатар, скрипт COM интерфейсінің объектілік моделі COM/DCOM интерфейсінің объектілік моделіне өте ұқсас, бұл әзірлеушілерге скрипт тәжірибесімен танысуды жеңілдетеді.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
DCOM және SOAP арқылы қашықтықтан басқару мүмкіндіктері: Басқару қашықтықтан басқаруға байланысты болғандықтан, WMI DCOM тасымалын ұсынады. Сонымен қатар, SOAP тасымалы Windows Server 2003 R2 бағдарламасында Microsoft, Intel, Sun Microsystems және Dell бастамалары арқылы WS Management бастамасы арқылы қолжетімді болады. Бұл бастама кез келген скрипттерді қашықтан орындауға немесе SOAP сұраныстарын және жауаптарды басқаратын интерфейстердің арнайы жиынтығы арқылы WMI деректерін пайдалануға мүмкіндік береді. WMI провайдерін әзірлеушінің артықшылығы - ол барлық мүмкіндіктерін WMI арқылы ашқанда, Windows қашықтан басқару / WS басқару өз кезегінде осы ақпаратты да пайдалана алады (WMI инстанцияларындағы кіріктірілген объектілер Windows Server 2003 R2-де қолдау таппайды. Алайда бұл Vista үшін мақсат болып табылады). WS Management-ке барлық қабаттау және CIM деректер моделінің SOAP-ке сәйкестігі WMI/WS Management шешімінен тегін шығады. DCOM қолданылуы керек болған жағдайда, DCOM-ды іске асыру үшін әр клиент машинасына орналастырылған прокси DLL болуы қажет. WMI Windows 2000 операциялық жүйесінде қолжетімді болғандықтан, бұл мәселелер жойылады.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Сұрауларды қолдау: WMI WQL сұрауларын қораптан тыс қолдайды. Бұл дегеніміз, егер провайдер сұрауларды қолдау үшін жасалмаса, WMI оны провайдерден шыққан санау техникасын қолдану арқылы қолдайды.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Оқиға мүмкіндіктері: WMI абонентке ол қызығушылық танытатын кез келген оқиға туралы хабарлау мүмкіндігін ұсынады. WMI WQL оқиға сұраныстарын жіберу үшін WMI Query Language (WQL) қолданады және қайтарылатын оқиғалардың түрін анықтайды. Барлық байланысты кері шақырулармен бірге оқиғалар механизмі WMI COM/DCOM және автоматтандыру интерфейстерінің бөлігі болып табылады. WMI провайдеріне жазған кез келген адам бұл функционалдылықтан өз клиенттері үшін ешқандай шығыссыз пайдалана алады. WMI провайдері және WMI кластар жиынтығы арқылы берілетін басқару туралы ақпаратты тұтынуды қалайтынын тұтынушы өзі шешеді.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Код үлгісін жасаушы: Барлық COM/DCOM интерфейстерін және байланысты анықтамалармен қоса WMI провайдерін жазу процесін жеделдету үшін WMI тобы провайдерді іске асыратын код үлгісін жасау үшін WMI ATL Wizard бағдарламасын әзірледі. Шығарылған код бастапқыда әзірлеуші жасаған WMI кластық моделіне негізделген. WMI провайдерін әзірлеуші WMI провайдерінің алдын ала анықталған COM/DCOM интерфейстерін өзінің жергілікті API жиынтығымен байланыстыруға қабілетті болады. Бұл жаттығу қажетті интерфейстік логиканы құру үшін провайдер кодындағы "бос орындарды" толтырудан тұрады.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Болжамдылық: Болжамдылық - IT-кәсіпкерлері үшін маңызды мәселе, өйткені ол Windows компонентін басқару интерфейстерімен тәжірибесі бар адамның осы білімін кез келген басқарылатын Windows компонентіне бірден, интуитивті түрде қолдану қабілетін анықтайды, ештеңені бастапқыдан үйренудің қажеті жоқ. Тұтынушы үшін болжамдылық - нақты пайда, өйткені ол Инвестицияның қайтарымын (ROI) арттырады. Мұндай жағдайға тап болған адам бұрынғы тәжірибесіне сүйене отырып, нәрселердің бірдей жұмыс істеуін күтеді. COM бағдарламалау/скрипт интерфейстерінің үнемі өсуі болжамдылыққа үлкен әсер етеді, өйткені бұл тұтынушылар үшін Windows-ты автоматтандыруды, басқаруды және қолданыстағы білімдерін пайдалануды қиындатады. WMI және CIM бұл мәселені басқарылатын объектіге қарамастан, әрқашан бірдей бағдарламалау объектілік моделін (COM/DCOM, Автоматтандыру, .NET) ұсына отырып шешеді.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Қолданыстағы клиенттік инвестицияларды қорғау: Клиенттер мен серіктестердің инвестицияларын қорғау оларды технологияларға инвестициялауға ынталандырады. Microsoft WMI провайдерлерін жазуға көп инвестиция салғандықтан, клиенттер мен серіктестер Windows мүмкіндіктерін пайдаланатын құралдарға инвестиция салды. Сондықтан олар әр басқарылатын Windows компоненті үшін жаңа интерфейстер жиынтығын пайдаланудың орнына осы мүмкіндіктерді пайдалануды жалғастырады. Интерфейстердің арнайы жиынтығы - компонентке немесе технологияға арналған жаңа модельге немесе интерфейстер жиынтығына негізделген арнайы агенттердің немесе ішкі әзірленген бағдарламалық құралдардың болуын білдіреді. Бүгін WMI мүмкіндіктерін пайдалану арқылы клиенттер мен серіктестер бұрын жасалған жұмысты пайдалана алады, сонымен қатар даму, оқу қиындықтары және жаңа жаңалықтар бойынша шығындарын азайтады. Бұл олардың инфрақұрылымының тұрақтылығы мен сенімділігіне де үлкен әсер етеді, өйткені олар жақсартылған технологиямен қолданыстағы іске асыруды жалғастырады.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Логикалық және біріктірілген басқару моделін ұсыну: Бұрынғыда кіріспеде қысқаша сипатталғандай, бұл модель DMTF (https://www.dmtf.org/) анықтаған өнеркәсіп стандарты CIM негізінде құрылған. CIM кластық схемасы өнеркәсіптің талаптарына жауап беретін құрылысшылар мен бағдарламалық құралдарды әзірлеушілер консорциумымен анықталған. Бұл Microsoft ғана емес, кез келген басқа үшінші тарап құрылысшылары немесе әзірлеушілер де модельге сәйкес өзінің кодын жаза алады дегенді білдіреді. Мысалы, Intel осыны желілік драйвер адаптерлерінің және бағдарламалық құралдарының кейбір бөлімдері үшін жасап жатыр. HP қолданыстағы WMI провайдерлерін пайдаланады және HP Open View Enterprise Management бағдарламалық құралында өзінің WMI провайдерлерін іске асырады. IBM Tivoli басқару жиынтығынан WMI-ды тұтынушы, MOM және SMS сондай-ақ WMI ақпаратын тұтыну және ұсынуда. Соңғысы, Windows XP SP2 антивирустік бағдарламалық құралдар мен брандмауэрлерден ақпаратты алу үшін WMI-ды пайдаланады.
For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
Automation interfaces:Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out of the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI. NET Management interfaces:Because the System. Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all NET applications independently of the language used (e. g. C#, VB. NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the NET Framework as this support is already available from WMI for free. C/C++ COM/DCOM programming interfaces:Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience. Remoting capabilities over DCOM and SOAP:More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated. Support for Queries:WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider. Eventing capabilities:WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes. Code template generator:To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic. Predictability:Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, NET) whatever the manageable entity is. Protect existing customer investments:Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology. Provide a logical and unified administration model:As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www. dmtf. org/). The CIM class based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti virus software and firewalls.
WMI драйверінің кеңейтулері
WDM-ге арналған WMI кеңейтімдері ядролық деңгейде құралдарды ұсынады, мысалы, ақпаратты жариялау, құрылғы параметрлерін конфигурациялау, құрылғы драйверлерінен оқиға туралы хабарлама жіберу және WDM провайдері деп аталатын WMI провайдері арқылы әкімшілерге деректер қауіпсіздігін орнатуға мүмкіндік береді. Бұл кеңейтімдер WDM архитектурасының бір бөлігі болып табылады, бірақ олардың қолданылу аймағы кең және басқа да драйвер түрлерімен (мысалы, SCSI және NDIS) де пайдаланылуы мүмкін. WMI драйверлік кеңейтімдер қызметі WMI немесе оқиғаларды іздеу туралы ақпаратты жариялауға конфигурацияланған барлық драйверлер мен оқиғаларды іздеу провайдерлерін қадағалайды. WDM үшін WMI кеңейтімдеріне арналған драйверлер арқылы құрал-жабдық деректері ұсынылады. WDM үшін WMI кеңейтімдері Windows-қа тән драйвер модельдерінде деректерді бақылауға арналған Windows құрылғы драйвер интерфейстері жиынтығын қамтамасыз етеді, соның арқасында OEM және IHV өндірушілер құрылғы деректерін оңай кеңейтіп, аппараттық-бағдарламалық шешімдерге құндылық қоса алады. Дегенмен, WMI драйверлік кеңейтімдері Windows Vista және одан кейінгі операциялық жүйелерде қолдау көрсетілмейді.
The WMI extensions to WDM provide kernel level instrumentation such as publishing information, configuring device settings, supplying event notification from device drivers, and allowing administrators to set data security through a WMI provider known as the WDM provider. The extensions are part of the WDM architecture; however, they have broad utility and can be used with other types of drivers as well (such as SCSI and NDIS). The WMI Driver Extensions service monitors all drivers and event trace providers that are configured to publish WMI or event trace information. Instrumented hardware data is provided by way of drivers instrumented for WMI extensions for WDM. WMI extensions for WDM provide a set of Windows device driver interfaces for instrumenting data within the driver models native to Windows, so OEMs and IHVs can easily extend the instrumented data set and add value to a hardware/software solution. The WMI Driver Extensions, however, are not supported by Windows Vista and later operating systems.