I have come up with a situation in which an installed antivirus is not detected by wmic or it's equivalent cmdlet. The system where I am having this issue is a windows server 2016 and the antivirus is SEP (Symantec Endpoint Protection)
While doing some research I have found two possible explanations for this, but as far as I understood, these answers are pretty different, actually could even be complementary. Since I am a newcomer to WMI I would like some clarification about them.
The command I am using for retrieving the information is:
wmic /NAMESPACE:\\root\SecurityCenter2 path antivirusproduct GET ...
The first explanation1 I found is that the antivirusproduct class is not defined in server versions of windows which fits my problem since my machine is a windows server and I have tried the same command on a Win10 machine and it works.
The second explanation2 talks about the fact that in order to detect the antivirus through WMI it has to be registered on the Windows Security Center.
Having said that the main questions are:
Is the antivirusprocut class defined by the Windows Security Center provider, actually, does WSC have a WMI provider. If not which WMI provider is defining this class. I have been looking at the list of providers in the reference documentation3 and there doesn't seem to be a provider defining this so I assume this must be set by a provider coming from a third party software, hence the guess about WSC.
Regardless of the provider why would a class be defined on windows desktop versions and not on a server ones.
Any clarification is appreciated.
1 Detecting anti-virus on Windows with WMI - which namespace?
2 https://support.moonpoint.com/os/windows/commands/wmic/determine-antivirus.php
3 https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-providers
Related
Occasionally, when we perform our maintenance cycle the domain controller will take too long and some of our virtual machines will default to the public network category instead of domain authenticated. After searching through BOL and Google, I found the Get-NetConnectionProfile cmdlet but it only seems to be available on Windows 2012 and later. We have some machines still running Windows 2008. I've already attempted to use the -CimSession switch to connect to a 2008 machine and it returned an error.
Is there a PowerShell equivalent for earlier versions of Windows?
The entire CIM cmdlet came out with Server 2012, and is representing this CimClass class which is a part of Windows Management Infrastructure(MI), also introduced in Server 2012. Which seems to be replacement of Windows Management Instrumentation(WMI), or in Microsoft's word:
The Windows Management Infrastructure (MI) features represent the
latest version of the Windows Management Instrumentation (WMI)
Thus is closest counter part you can get is Get-WMIObject cmdlet in eailer OS. The item you looking for, should be MSFT_NetConnectionProfile. Unfortunately I didn't find anything similar from get-wmiobject -list. I also checked documentation here Networking Device Classes without luck.
If you give get-wmiobject a shot, I don't expect it would return things exactly the same, but maybe some wmi object(s) would return the item you care most?
The win32_clustershare does not have a Create method on win2008r2? How does one create file shares using ideally wmi?
I thought the Win32_ClusterShare class was read only, but could be mistaken.
To do it without WMI, you can use the cmdlets in the FailoverClusters module, but you'll probably have to install Windows Management Framework 3 or (preferably) WMF 4 on your Windows 2008 R2 machine since these cmdlets aren't available in Powershell 2.0.
With 3.0+, you should be able to use Add-ClusterResource and the related cmdlets.
Apparently the win32_clustershare.create does not work as expected and is broken. Previously this class was absent altogether from windows as indicated here-
http://support.microsoft.com/kb/971403
Apparently Using win32_share does the needful even for clusters. I confirmed in HKLM\Cluster\Resources that the share is properly registered in the cluster.
Apparently windows is able to determine that the share upon creation is properly associated with a clustered disk.
I know I am not calling the win32_clustershare wrong, because I confirmed that the parameters are identical across the 2 wmi classes.
This is evident in inspecting both
(get-cimclass -ClassName win32_share).CimClassMethods["Create"].Parameters |fl *
(get-cimclass -ClassName win32_clustershare).CimClassMethods["Create"].Parameters |fl *
If you are using Windows Server 2012 R2/Windows 8.1, you can use the new and much improved SMB PowerShell modules. Have a look at https://technet.microsoft.com/en-us/library/jj635726(v=wps.630).aspx and http://windowsitpro.com/powershell/managing-file-shares-windows-powershell
Environment:
I work in a lab that tests software against multiple domain configurations. I currently have 8 domains with no cross-domain trust. They each have a WSUS server that talks to our primary NOC WSUS Server. Other than talking to the primary WSUS server, there is no communication from one domain to the other. I cannot change GPO settings or install any software that isn't already installed. The domains range from Windows XP with Server 2003 to Windows 7 with Server 2008. Each domain has anywhere between 8-20 servers and 3-5 workstations.
I have a machine that can talk to each of the servers in all of the domains, and can also talk to the primary WSUS server. I primary work with PowerShell, but I'm not opposed to another language if it makes what I'm trying to do easier. I have PowerShell 2.0 installed, but I can easily installed PowerShell 3.0 if needed.
Scenario:
I am charged with checking if patches have been installed on each of the servers. This testing cannot rely on WSUS's built in reporting tools, per requirements I cannot change. I would receive a list of patches, and I need to check each server to see if the patches are installed. Since the patches can be anything from Windows XP to Server 2008, I also need to check if the patch is applicable to the server itself. I have tried to use PoshWSUS to check for applicability, but I cannot get a connection to the Primary WSUS server because of either IIS rules or a Firewall rule. I have search online, and followed several guides, but this WSUS's setup is very customized, and I can only do so much to the server itself.
Example:
I have the following Patches:
KB2604092
KB2676562
KB2686509
I want to check the following server:
DC01: A Windows Server 2008 Domain Controller
I am currently using the following PowerShell command to test if they are installed:
Get-HotFix -ID "KB2604092","KB2676562","KB2686509" -ComputerName DC01
This command shows the following patches are installed:
KB2676562
KB2686509
Leaving the following uninstalled:
KB2604092
This correctly tells me that KB2676562 and KB2686509 are installed, but it doesn't tell me if KB2604092 missing, or not applicable.
What I am stuck on is how to verify that KB2604092 is not applicable to DC01. I can easily search Microsoft's site to verify it is only for Windows Server 2003 or Windows XP, but how can I check it's applicability via a script. I would love to find a way to scrap the Microsoft KB article for the data, but I don't know how to pull the required information from the web page. I assume there has to be a check within WSUS to check applicability, but I don't know where to look for something like that.
Edit:
I forgot to mention, I have no control over what patches are approved, that is done by an outside company.
Well for security patches, Microsoft publishes a a spreadsheet that lists the all security bulletins since 1998. You can download from this page. (Direct link to spreadsheet)
You could then parse that spreadsheet (if you convert it to a CSV file, that would be easy to parse in powershell). It gives you all the information you are asking about.
If you're only interested in whether the update is applicable to the corresponding operating system, IUpdate.ProductTitles should give you the information you need.
There are more complicated cases, such as where an update is applicable only if a certain system component is installed. I don't think there's any way to handle those cases automatically.
I'm looking for a way to obtain information similar to the following console applications, remotely:
net use
net share
netstat -ano
However, I need to be able to do this without running a 3rd party application on the system. This effectively rules out using psexec to execute the command remotely, because psexec would then be installed as a service.
I should add that I have administrative credentials on the remote system. I've considered using WMI's remote execution ability, but that requires me to write output to a file and then retrieve it. It's possible, but I'd like to know if anyone has a better way.
I am using Delphi 2010.
there are a couple Delphi WMI components that allow remote access. I have not used the remote options personally though.
MagWmi - http://www.magsys.co.uk/delphi/magwmi.asp (Delphi 2010 support, and free with source)
WMISet/NTSet - http://www.online-admin.com/ntset.html (TNTShare
Manages shared resources on a local computer and remote hosts. Using this component you can change list of shared devices, see files that have been opened by remote users, watch and terminate remote sessions opened to the destination computer, change list of mapped network drives. It is not free.)
GLibWMI - Found at Torry.net, home page not available. (Delphi 2010 support and Freeware with source). Not sure if its capable of remote access. I have not used it.
Hope this helps
I think the same as Logman.
You can access this information using WMI.
GLibWMI components can be found on this website (http://neftali.clubdelphi.com) or sourceforge (http://sourceforge.net/projects/glibwmi/).
The current version is 1.8b and has a component called SharedInfo with which you can get that information.
The source code is available so you can expand it to access other WMI classes if necessary.
Regards.
P.D: Sorry for my mistakes with english.
You can enumerate shares using the NetShareEnum function (headers are in the Jedi Apilib).
I assume there must be an api for the "net use" but I have never used it (check the WNet functions). Alternative is to use the EnumNetworkDrives method of the WshNetwork com object.
As for netstat I don't think it's possible to do that remotely (other than using some kind of method to spawn a process remotely).
I'm adding WMI publishing to a .net framework 3.5 based windows service that is running under the 'network service' account.
According to a document I came across on MSDN, the 'network service' account should by default have WMI publishing permissions. ("By default, the following users and groups are allowed to publish data and events: ... Network Service, ...")
However, when the service calls Instrumentation.Publish(myStatusClassInstance), it throws a DirectoryNotFoundException;
System.IO.DirectoryNotFoundException was unhandled
Message: Could not find a part of the path 'C:\Windows\system32\WBEM\Framework\root\MyWMINamespace\MyService_SN__Version_1.0.3686.26280.cs'.
..so it looks like System.Management.Instrumentation tries to generate code on the fly, and when running under network service it targets a directory where network service has no permissions.
What is the best fix/workaround for this? Can I override the code-gen target dir in app.config or in code? I don't want to have to fiddle around with file system permissions when deploying the service...
Update: I think this is a 'feature' where older FX code clashes with newer security settings in Win7. Internally the WMI managed classes retrieves the WMI installation directory from registry, and uses that as the output path for generated code. Unfortunately a lot of users are not allowed to (or supposed to) write stuff under %SystemRoot%... ...I filed a connect bug (#530392) to see if MSFT can bring any clarity and/or provide a fix or workaround.
Update 2: I'm guessing that for normal user accounts this is not an issue, because UAC virtualization will kick in and store the files elsewhere. However, apparently the 'network service' account is not covered by UAC virtualization..(?)
Update 3: Added 550pt bounty. Simple constraints: .net framework 3.5 based windows service, running as network service, need to be able to publish data through WMI using System.Management.Instrumentation on Win7 and Win2008[RTM & R2] with default permissions/security settings and without resorting to modifying framework internal/private members using reflection. 'Out-of-the-box' but clean solutions welcome. Will open a second related bounty-Q as a placeholder for another 550pt if SO allows.
Bounty update: I intend to double the bounty for this Q through a second hand-in-hand question that will serve as a bounty placeholder:
https://stackoverflow.com/questions/2208341/bounty-placeholder ( <-- Apparently this was not allowed, so the bounty placeholder question got closed by the SO etiquette police.)
Update 4: This gets better and better. I noticed that installutil was writing the missing files to c:\windows\syswow64...etc..., so I realized that I was using the 32-bit version of installutil to install the service, but the service was running as a 64-bit process. The obvious side effect was that code generated when installutil was running ended up under syswow64 (the 32-bit system directory), while the service was looking for it under the 64-bit system directory (system32). (<-- off topic, but I really like how MSFT managed to switch around the names there... :) ).
So I tried installing the service with the 64-bit version of installutil. That failed miserably with permission errors in the %sysroot%\wbem\framework...etc... path. Next I recompiled the service as x86 and registered it again using the 32-bit version of installutil. That resulted in an entirely new exception:
System.Exception: The code generated for the instrumented assembly failed to compile.
at System.Management.Instrumentation.InstrumentedAssembly..ctor(Assembly assembly, SchemaNaming naming)
at System.Management.Instrumentation.Instrumentation.Initialize(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetInstrumentedAssembly(Assembly assembly)
at System.Management.Instrumentation.Instrumentation.GetPublishFunction(Type type)
at System.Management.Instrumentation.Instrumentation.Publish(Object instanceData)
at SomeService.InstanceClass.PublishApp(String name) in e:\work\clientname\SomeService\SomeService\WMIProvider.cs:line 44
at SomeService.SomeServiceService..ctor() in e:\work\clientname\SomeService\SomeService\SomeServiceService.cs:line 26
at SomeService.Program.Main() in e:\work\clientname\SomeService\SomeService\Program.cs:line 17
...getting closer...
I believe the problem is not with publishing data, but with registering that type in WMI for the first time.
If you examine the System.Management.Instrumentation code in reflector, or some other disassembler, you'll see that wen the assembly that is about to publish hasn't been registered, then the code will try to register the assembly and save the assembly info in a specially named sub directory under the WBEM installation folder.
I suspect that if you run code to publish the WMI data as an administrator first, it would register the assembly and then the Network Service account would have the permissions to do the normal publishing.
Have you inspected your assembly with the installutil? That should give you a log of the installation issues. (But since you can't run it as the Network Service account, it might not show the problem you're having.)
Also, are you sure this service must be run under the Network Service account?
Because of the vulnerability risk in running Windows services in privileged accounts, Microsoft has made these special service accounts with some limitations, which were strengthened in Vista and Win7. Since Vista, Microsoft has limited the number of services running under this account in favor of less-privileged ones (see this article). The Network Service account (aka "NT AUTHORITY\NETWORK SERVICE") can access the network (acting as the local machine account PCNAME$), but it has reduced rights on the local machine (unlike the Local System account).
Have you checked the WMI security permissions for the branch your assembly is using? Run wmimgmt.msc and dig in... When I did a quick check of some random branches, I could see that the Network Service account did not have write rights.
Lastly, I would suggest using Sysinternals' ProcMon, which would allow you to filter to just that process and see if there are any Access Denied errors in file or registry settings. This tool has solved many problems for me over the years.
Not sure if you raised it or someone else but please have a look:
http://connect.microsoft.com/VisualStudio/feedback/details/530392/wmi-publishing-fails-on-permission-error-please-provide-a-way-to-override-codepath-in-system-management-instrumentation-schemanaming-in-app-config-web-config
This may help you to understand the root cause of the issue better