In our Powershell deployment scripts we terminate inflight instances identified by the following query:
get-wmiobject -namespace Root\MicrosoftBizTalkServer -query "SELECT * FROM MSBTS_ServiceInstance WHERE (ServiceClass = 1 OR ServiceClass = 64) AND AssemblyName LIKE 'Our.AssemblyName'"
For some reason this has stopped working on a Windows 2016 server, failing with this message:
get-wmiobject : An internal failure occurred for unknown reasons.
At line:1 char:1
+ get-wmiobject -namespace Root\MicrosoftBizTalkServer -query "SELECT * ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Get-WmiObject], COMException
+ FullyQualifiedErrorId : GetWMICOMException,Microsoft.PowerShell.Commands.GetWmiObjectCommand
Some searching has pointed to recent OS security patches. We uninstalled the KB mentioned from all nodes.
The above query runs without failure on 2 nodes in one environment and 1 node in another. This one box still gives the above error. Not sure what caused the original problem but maybe the uninstall did not clean up properly.
Any ideas where to start looking to fix the problem? I was thinking maybe installing the patch again and uninstalling it to make sure it cleans up properly. It takes about 4 hours for the VM to boot after the uninstall so testing such theories take a long time.
Turns out we have auto patching that kept re-applying the patch. What added to the confusion was the patch number being different for each OS and then there is the 4 hour thing that made it really difficult to poke the issue.
On 2016 it is KB4345418 that is causing the problem.
Related
Afternoon everyone. I'm running into an issue I'm not sure how to handle. I'm working on a script for work to deploy a Domain Controller using PSremoting. It all works well in fine until I get to where I'm importing some GPOs from backups.
*All the commands are run under invoke-command
I run the command Import-GPO -BackUpName $GPO -TargetName $GPO -Path $GPOPath -MigrationTable $MigTable -CreateIfNeeded
When I run this, I get an error on the host:
Operation is not valid due to the current state of the object.
+ CategoryInfo : NotSpecified: (:) [Import-GPO], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.GroupPolicy.Commands.ImportGpoCommand
+ PSComputerName : v204-DC1
I can't seem to find anything that says what this means. When I check for the GPOs on the DC, they all show up and seem to be linked properly. I am curious what this error is, or if I should just append -ErrorAction SilentlyContinue to the end of my code.
Ended up being an issue with my migration table. I rolled back to an earlier one and ended up being good to go
I installed PSFramework on my W2k12 server. However when I run an import-module PSFramework I get the following error:
Exception calling "InvokeGlobal" with "0" argument(s): "Parameter count mismatch."
At C:\Program Files\WindowsPowerShell\Modules\psframework\1.6.181\PSFramework.psm1:7348 char:2
+ $isInstalled = $provider.IsInstalledScript.InvokeGlobal()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : TargetParameterCountException
This works fine on my Win 10 machine.
Any ideas?
Thanks in advance,
Jake.
I'm the maintainer of PSFramework, sorry about that fail!
One of my security-related feature updates broke PSv3 & PSv4 support, I didn't notice right away and then was drowned in heavy workload to fix it timely.
I've added an issue that you can track until it is resolved:
https://github.com/PowershellFrameworkCollective/psframework/issues/474
In the meantime, you can resolve this on your server by updating its PowerShell to v5.1 as Mathias suggested, which will resolve it right away.
I am running a simple cmdlet with Powershell 5.1, winver 1803.
I am running:
Rename-Computer -ComputerName $pc -NewName $newName -DomainCredential $cred -Restart
This command is part of a script. Everything in the script works - and this line used to work, but for some reason it stopped.
The exception is:
Fail to rename computer '$pc' to '$newName' due to the following
exception: Not enough quota is available to process this command.
There are no memory or page-file size issues. There are no other applications even running. Page file size is in excess of 8GB.
WinRM is running, stack 3.0.
Why on earth is this command producing this error? How might I troubleshoot it?
UPDATE
This is what I am seeing...
Rename-Computer : Fail to rename computer 'W4000100' to 'W1401-TR100'
due to the following exception: Not enough quota is available to
process this command. At line:2 char:9
+ Rename-Computer -ComputerName $pc -NewName $newName -DomainCr ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (W4000100:String) [Rename-Computer], InvalidOperationException
+ FullyQualifiedErrorId : FailToRenameComputer,Microsoft.PowerShell.Commands.RenameComputerCommand
Rename-Computer : Fail to rename computer 'W4000100' to 'W1401-TR100'
due to the following exception: Not enough quota is available to
process this command. At line:2 char:9
+ Rename-Computer -ComputerName $pc -NewName $newName -DomainCr ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (W4000100:String) [Rename-Computer], InvalidOperationException
+ FullyQualifiedErrorId : FailToRenameComputer,Microsoft.PowerShell.Commands.RenameComputerCommand
Again, this same message pops up if you try to rename a computer locally via the GUI, and also happens if I remove the hyphen from the name, etc.
After researching, I believe this solution may solve your issue from the following article by Phil Coutard:
http://blog.coultard.com/2012/01/fix-windows-error-0x80070718-not-enough.html
This might be set on the user level. Try going to Control Panel, Sync Center, Offline Files, Manage Offline Files (left hand side), Disk Usage tab, Change Limits. It could be that your Disk Usage has a limit. Try that first and see if that fixes it.
UPDATE:
If that doesn't work, since the error is so generic, I would recommend using Microsoft's Automatic diagnostic/repair tool: https://support.microsoft.com/en-us/help/17590/automatically-diagnose-and-repair-windows-file-and-folder-problems
The answer after troubleshooting with MS is that the image used for these systems was domain-joined at the time of capture. This results in each machine having the same AccountDomainSID, which apparently can cause many issues - however, this is the only issue we have identified as a result.
MS have pretty much stopped researching with me and say this is the cause and that the only fix is to remove from domain and rejoin.
I'm writing a Powershell script to do some server management when we have a power outage. Presently the script is using the WMI Win32)Battery class to see if BatteryStatus is a 1 (discharging) or a 2 (unknown (on A/C)) but I am not sure this is the best method. There are several statuses that could be true at the same time.
For example, the battery could be Discharging (1) and Partially Charged (11) or On AC (2) but Critical (5) or charging (6) or Partially Charged (11). This doesn't make sense to me. Is BatteryStatus reliable for my intended purpose? How does Windows determine which status is returned? In my testing I've not seen anything other than statuses of 1 or 2.
The documentation for Win32_Battery indicates Availability might also be an indicator that we are on battery. Is that a better way to go, maybe a combination of BatteryStatus and Availability?
In my search for answers I came across what looks like the perfect answer, using "PowerOnline" from the undocumented BatteryStatus class in the root\wmi namespace. This works great from my laptop but I get the following error when trying to access it from our Windows 2012 server:
PS C:\Windows\system32> gwmi -Class batterystatus -Namespace root\wmi
gwmi : Invalid class "batterystatus"
At line:1 char:1
+ gwmi -Class batterystatus -Namespace root\wmi
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidType: (:) [Get-WmiObject], ManagementException
+ FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand
Is this class not available on servers?
So using WMI, what is the most reliable way to know if I am on UPS battery or AC Power?
I am putting together a script which will log off VDI sessions which have been in a disconnected state for over 10 hours. I have managed to get everything together except for the last hurdle - actually forcing a logoff.
ForEach ($Desktop in $VDIlist)
{
$win32OS = Get-wmiobject win32_operatingsystem -ComputerName $desktop.'DNS Name' -EnableAllPrivileges
write-host "Shutting down host $Desktop."DNS Name""
$win32OS.Win32Shutdown(4)
}
This results in the error below.
Exception calling "Win32Shutdown" : "Generic failure "
At line:1 char:1
+ $win32OS.win32shutdown(4)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WMIMethodException
This does not appear to happen when no argument is used
($win32os.win32shutdown()), but this also does not force the log off like I require.
As far as I have read the -EnableAllPrivileges parameter should allow for the remote log off and it does work if I have a live PCoIP session to the VDI I am attempting to shutdown but not when in a disconnected state.
Could anyone point me in the right direction?
Still not entirely sure why the first script is giving an error but I have instead switched to using VMWare View's built in PowerCLI snapin to produce the same result - just faster and more efficiently.
get-remotesession -state "Disconnected" | Where-Object {($_.duration -match 'Day' -or $_.duration -match '\d\d hours')} | Send-SessionLogoff
This will query the Horizon view server for any sessions with the "Disconnected state", it will then filter out any objects that have had a lifetime of less than 10 hours and log off anything that is left.
This requires VMware View PowerCLI PSSnippets to be loaded and connected to your view connection broken.