none
Powershell Script to create a custom wmi namespace and Class to return Registry Value RRS feed

  • Question

  • Hi all,  I'm struggling to use powershell to create a custom WMI namespace and class that will return a single specific registry value.  It seems like I need this specific functionality due to the following situation:

    I manage 2000 Virtual Desktops with a printer policy with over 400 printers.  Processing that printer policy takes an undue amount of time at logon due to the volume of printers.   I'd like to break the printer processing up into multiple policies targeting specific locations and use standard Microsoft GPO WMI filtering to achieve that goal. 

    This would allow me to process a much shorter list of printers for each user.  The goal would be to return the registry value of the IP address of the Thin Client the user is connecting from inside of the registry of the Windows 10 VDI node to which they are attached and use that in a WMI filter for Group Policy using the standard Microsoft GPO Toolset. 

    The problem is I need to read the registry to collect the IP address of the Thin Client attaching to the VDI node to know what printers are nearby to it.

    And, Although you can read the registry via WMI easily the WQL language used by Microsoft to filter policies does not support WMI methods.  You can only call classes and properties in WQL - Methods are expressly not supported. 

    All the standard builtin registry tools for WMI that I have found use Methods.  Since I can't use Methods in WQL those tools won't work for me in this effort.  Although it was very educational learning about them!     

    Since I can't use a WMI Namespace\class\Method to achieve the goal.  It seems like the best idea may be to create a custom Namespace\Class\property that is hard set to returns just the single registry value that will hold the Thin Client's IP address.  

    Ideally I want to write a script that will create a custom Name Space, ( This I've found many examples of online) and then create a custom class with a property that contains a string retrieved from that specific registry value.  

    I've found links to the Powershell WMI-Module written by Stephane Gulick and it's great.  Creating a custom Namespace and class is relatively easy using powershell with these tools.  But what I can't find is how to then create a property under the class that would return a specific registry value.   Lots of examples on using Methods to read the registry but again methods won't work for me in 



    Does anyone know of an example to do something like this?

    To summarize: 

    1.  Here is the registry value I need to return in WQL to filter policy:  HKLM\SOFTWARE\Citrix\Ica\Session\ClientAddress

    2.  To use GPO WMI filters I need to create a WMI WQL query similiar to "select IPAddy from MyNamespace WHERE IPAddyFromRegistry like “10.0.134” 

           Please remember you cannot use WMI Methods here only Properties as a limit of WQL! 

         

    3.  So  I need to create the Custom WMI namespace "MyNameSpace"   

    4.  Once the name space is created I then need to create the class IPAddyFromRegistry

    5.  I need to populate the class with the value from  HKLM\SOFTWARE\Citrix\Ica\Session\ClientAddress

    I know this is convoluted and if anyone has any other thoughts on how to achieve the same goal I'm open to hear them! 





    Tuesday, December 3, 2019 5:27 PM

All replies

  • Wouldn't it be simpler to create multiple OUs and filter based on OU location (or something similar)?

    But in any case, this isn't really a good forum for this as you don't really have a scripting question per se.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, December 3, 2019 5:34 PM
    Moderator
  • The challenge is that you will have to write code in C or C# to produce that results then use that code in WMI to implement the class.

    The need to allocate printers by location is something that would best be done by using "sites and subnets" to assign printers.  There are two places where you can get assistance with how to do this; printer forum and the Directory Services forum.

    The Group Policy forum can also help you understand how to use the AD "location" capability to assign the closest printer.


    \_(ツ)_/


    • Edited by jrv Tuesday, December 3, 2019 5:54 PM
    Tuesday, December 3, 2019 5:53 PM
  • I'm well versed in Sites and Subnets.  The comments about that and also OUs for filtering are appreciated but pose more management overhead than they are worth to some degree.  Basically re-architecting for those thing would add more management burden than other ways we are solving the printing issue today.

    We are running non-persistent VDI and once we create sub OUs and put specific VDI nodes into specific OUs and assign policy per alot of the economies of scale for Non-Persistent VDI starts to disappear.  

    Site and Subnets won't work as that policy is based on the IP address of the OS processing policy - in this case the Win10 VDI node in the data center.  But I actually need the filtering based upon the IP of the thin client whose IP is stuck in the aforementioned registry value above.  And there is no way with Site Policy to extend filtering to that value.  I believe I'm closer to that goal with the WQL filtering in general GPO than I would be with Site Policy.    All 2000 VDIs are on one subnet (literally 1 giant subnet)  in the data center in the same site.  So it won't work for us from that perspective. 

    We've done some other tricks so far and our issue is not critical but if I can find a way to achieve this goal it would definitely help.  If I need a C programmer to achieve the goal I can start looking for that as well. 

    Sorry to spam the scripting forum - but I thought this best place to reach people who might understand the complexities.  From the 2 responses so far I do think the audience is sophisticated enough to get the gist which might be a challenge on some other forums!   

    Thanks for the responses so far. 

    Tuesday, December 3, 2019 6:12 PM
  • As noted above - you need to post this issue in a developer forum that can help you understand how WMI works and how you can create custom classes that do custom things.

    WMI registry support does not work with WMI filtering in AD.  It requires a multipart provider.  WMI filtering is "instance" oriented and without custom compiled code you cannot have an instance that does what you need.

    The solution requires more management overhead than using standard practices.  You also do not seem to know how location awareness can be used to allocate printers which s the built-in method for doing this in AD>

    You are also asking for us to design a solution.  That is beyond the scope of these forums.  I also recommend looking at third party print management solutions which will have tools that can help you manage printer allocations by location.  They normally use standard methods but perform the AD and GP updates for you.


    \_(ツ)_/

    Tuesday, December 3, 2019 6:32 PM
  •   


    Thanks,  I appreciate the input.  And I'll take this question elsewhere.  It does seem I've confirmed that there is not an easy way to do this in Powershell.  I understand that I want a two part solution for WMI filtering in AD - I was just hoping I could use powershell for second part of that solution - as that is the programming tool I know well. 

    It sounds like I can't use that hammer on this nail which is what I wanted to confirm.  

    I'll go look for a bigger hammer.  

    AD location will not solve the problem, and I'm well versed in 3rd party tools like Thin Print, Screw Drivers and all the rest of the standard VDI toolkits used to solve similiar issues.  To be honest after dealing with them for 20 years I find extending Microsoft Standard Tools to their fullest extent works best for most customers with at little custom scripting or code as needed. 

    I really like to solve issues keeping thing mostly in the Microsoft Wheelhouse and extending those tools to their fullest.  AD Site Policy which is what I think you are referring to won't work as all the VDI Nodes are in 1 site by design for lots of other reasons I won't go into.  And we achieve tremendous economies of scale managing them that way - so changing that for a relatively minor printer complaint is not worth it.

    Users are spread across 200 sites and move site to site regularly.  All other settings for users are controlled via User Loopback policy.  But for printing we want to connect to the printers on the local subnet of the VDI Thin client only.  We can't assume users are tied to sites.  And all VDI nodes are tied to a single site.  There fore we must read the VDI Thin Client IP (or name  

    That is the issue - the VDI Thin Client lives outside of MS AD and is not part of sites. and we can query it in AD Group Policy Preference without issue. 

    But we cannot currently use it to pre-filter AD GPO to limit the amount of printer records AD has to process as "Do Nothing" events during logon.

    The only way to reference that thin client location - is querying the registry of the VDI Node once the user has connected to it something not currently supported in any way before the AD Group Policy engine fires up and Group Policy Preference is available to us.  But at that point we are already loading a policy with 2 many line items to process quickly. 


    I've designed my solution - now i just need to go find the right hammer to provide the data for my WQL query.  Appreciate the input and I hope the complexities above make sense!  You seem interested so I thought I'd post all the details.   

    Historically we've had a custom powershell script fire in the user session that maps the printers based on a CSV file of all the settings.  But editing the CSV file has become problematic with scale and some of our Admins have asked me to find a way to achieve the goal by editing Group Policy objects instead of the CSV file. 



    Again, I was really just looking to make sure I hadn't missed an easy solution in the powershell realm.  I've got access to some C developers and can reach out to them to see if they can help.    

    Thanks,  BP.  


    Tuesday, December 3, 2019 7:16 PM
  • This can al be done with location awareness. Part of the issue is that you are trying to apply NT4/NetBIOS thinking in a modern W2K AD environment and the old definitions lead you down blind alleys.

    Toolkits are not what I am referring to.  Full print management solutions are the correct third party tools to look into.  Also Windows Print Manager can define and allocate printers and does create correct GP policies to apply these allocations.

    In any case there is no direct way to use scripting to create a WMI solution although you could create a WMI event that would execute a script.  Unfortunately the WMI event would have to be distributed to all computers which adds extra complexity.


    \_(ツ)_/

    Tuesday, December 3, 2019 7:24 PM