none
WINNT provider works incorrectly RRS feed

  • Question

  • Hello!

    Consider this script:

    ON error resume next
    StrComputer = "test226.domain.local"
    
    'Set objService = GetObject("winmgmts:{(Security)}\\" & strComputer & "\root\cimv2") '- OPTION1
    Set objService = GetObject("WinNT://"& StrComputer)                                    '- OPTION2
    
    If Err.number <> 0 Then
      WScript.Echo "ERR <> 0 ! - Connection to " & StrComputer & " FAILED!"
      WScript.Echo "Error " & Err.number
      WScript.Quit
      Else
      Wscript.Echo "Connection to " & StrComputer & " was established successfully!"
    End if

    The computer test226.domain.local does NOT exist so 'GetObject' should end up with an error regardless of the provider being used (WMI or WinNT).


    The results:

    1) When using OPTION1 -

    Set objService = GetObject("winmgmts:{(Security)}\\" & strComputer & "\root\cimv2")

    - all works as expected:

    2) When using OPTION2 -

    Set objService = GetObject("WinNT://"& StrComputer ) 

    - no error raises:

    Is it a bug in the WINNT provider?

    Thank you in advance,

    Michael


    • Edited by MF47 Wednesday, March 4, 2015 9:08 AM typo
    Wednesday, March 4, 2015 9:04 AM

Answers

  • Not a bug. The WinNT provider does not verify an ambiguous name exists when binding.

    However, if you specify the object class in your moniker string, it should return an error:


    Set objService = GetObject("WinNT://"& StrComputer & ",Computer")
    


    -- Bill Stewart [Bill_Stewart]

    • Proposed as answer by Bill_StewartModerator Thursday, March 5, 2015 3:18 PM
    • Marked as answer by MF47 Friday, March 6, 2015 8:00 AM
    Wednesday, March 4, 2015 3:23 PM
    Moderator

All replies

  • Not a bug. The WinNT provider does not verify an ambiguous name exists when binding.

    However, if you specify the object class in your moniker string, it should return an error:


    Set objService = GetObject("WinNT://"& StrComputer & ",Computer")
    


    -- Bill Stewart [Bill_Stewart]

    • Proposed as answer by Bill_StewartModerator Thursday, March 5, 2015 3:18 PM
    • Marked as answer by MF47 Friday, March 6, 2015 8:00 AM
    Wednesday, March 4, 2015 3:23 PM
    Moderator
  • Yes, it works!

    ...but it sounds strange to me: it means the explicit class notation in the moniker makes WinNT provider behave differently...

    And the error is not the same as with WMI provider:

    - I suppose it's because different providers should raise different errors, right?

    Just one more question please: would you point me to some document/article on constructing monikers for WinNT provider? I'm constructing them based on this document:

    https://msdn.microsoft.com/en-us/library/aa389292%28v=vs.85%29.aspx

    ...and this article gives other notation for classes:

    "The following moniker retrieves American English localized descriptions for the myclass class from the root\wmi namespace.

    "WinMgmts:[locale=ms_409]!root/wmi:myclass"


    Regards,
    Michael



    Thursday, March 5, 2015 9:37 AM
  • WinNT is a provider.  It calls the ADSI API with COM.  WMI is a service accessed through a COM reference that looks similar to a provider.

    You cannot compare them as you are.

    They behave differently because they are completely different things and APIs.


    ¯\_(ツ)_/¯

    Thursday, March 5, 2015 10:32 AM
  • jrv is correct. ADSI and WMI are two completely different things.

    -- Bill Stewart [Bill_Stewart]

    Thursday, March 5, 2015 3:18 PM
    Moderator
  • "ADSI and WMI are two completely different things." - I don't argue about it. I just thought that even "completely different things and APIs" must comply with a common VBscript logic (as well as with any other programming language's logic). I don't see how one can predict what extra moniker string(s) would be required by various providers/services.

    Bill_Stewart, jrv, thank you very much for your help!

    Regards,

    Michael


    • Edited by MF47 Friday, March 6, 2015 8:00 AM
    Friday, March 6, 2015 8:00 AM