Back a while ago I had a short post about uninstalling the SCVMM agent from Server Core.
That was an older version of Server and an older version of PowerShell.
Today, I had a reason to revisit that process. But now I have a bit more finesse with PowerShell and PowerShell is now in its v4 revision with Server 2012 R2.
And, needless to say, it is considerably simpler.
I am simply going to capture and paste my PowerShell screen and allow you to sort out the rest by reading through it. I think you will understand it simply enough.
PS C:\> Get-WmiObject -Class win32_product | ft
IdentifyingNumber Name Vendor Version Caption
----------------- ---- ------ ------- -------
{1D8E6291-B0D5-35EC-... Microsoft Visual C++... Microsoft Corporation 10.0.40219 Microsoft Visual C++...
{3834A905-5CC1-454D-... Microsoft System Cen... Microsoft Corporation 3.2.7510.0 Microsoft System Cen...
{A89BBF08-D933-4634-... Microsoft System Cen... Microsoft Corporation 3.2.7620.0 Microsoft System Cen...
PS C:\> Get-WmiObject -Class win32_product
IdentifyingNumber : {1D8E6291-B0D5-35EC-8441-6616F567A0F7}
Name : Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
Vendor : Microsoft Corporation
Version : 10.0.40219
Caption : Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
IdentifyingNumber : {3834A905-5CC1-454D-8CA4-AC449F12775D}
Name : Microsoft System Center Virtual Machine Manager DHCP Server (x64)
Vendor : Microsoft Corporation
Version : 3.2.7510.0
Caption : Microsoft System Center Virtual Machine Manager DHCP Server (x64)
IdentifyingNumber : {A89BBF08-D933-4634-8FBB-EB88F870981B}
Name : Microsoft System Center Virtual Machine Manager Agent (x64)
Vendor : Microsoft Corporation
Version : 3.2.7620.0
Caption : Microsoft System Center Virtual Machine Manager Agent (x64)
PS C:\> $installed = Get-WmiObject -Class win32_product
PS C:\> $installed[1].Uninstall()
__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 1
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
ReturnValue : 0
PSComputerName :
PS C:\> $installed[2].Uninstall()
__GENUS : 2
__CLASS : __PARAMETERS
__SUPERCLASS :
__DYNASTY : __PARAMETERS
__RELPATH :
__PROPERTY_COUNT : 1
__DERIVATION : {}
__SERVER :
__NAMESPACE :
__PATH :
ReturnValue : 0
PSComputerName :
PS C:\> Get-WmiObject -Class win32_product
IdentifyingNumber : {1D8E6291-B0D5-35EC-8441-6616F567A0F7}
Name : Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
Vendor : Microsoft Corporation
Version : 10.0.40219
Caption : Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
PS C:\>
Tuesday, April 29, 2014
Tuesday, April 8, 2014
Most useful Desired State Configuraiton debugging commands
Okay, here they are:
Get-ScheduledTask "Consistency" | Start-ScheduledTask
This will immediately re-process a configuration.
My scenario is this:
I place my configuration on a pull server.
I then configure the DSC Local Configuration Manager with the GUID of that configuration.
Then I can tweak the configuration and play with it, and not have to push it each time.
Running the consistency command allows me to 'do it now' and force a configuration to be applied, instead of waiting for my configured application window of time to pass.
Trace-xDscOperation | where { $_.EventType -eq "error" } | fl
This requires that you have the xDscDiagnostics module on your target machine. (Which if you are sorting out using DSC and applying configurations - this is necessary).
Lots of folks have blogged about it.
And it is handy with only two commands Get-xDscOperation and Trace-xDscOperation and the value add that it will enable tracing for you the first time you run in. Usability is high in this one.
Get-xDscOperation shows the job list.
Get-xDscOperation
This error you will always see the first time you apply a configuration.
If you want to know if DSC is chugging along and doing its thing you have to check the status of the consistency job:
Get-ScheduledTask "Consistency"
TaskPath TaskName State
-------- -------- -----
\Microsoft\Windows\Desired State Configurat... Consistency Running
Now, lets look at another failure to see the details.
Trace-xDscOperation | where { $_.EventType -eq "error" } | fl
There is good detail in here, you just have to find it.
[Script]MediaDownload is one of my configuration items. It is the Script Resource Provider (that is necessary context for the next)
The detail of the error is actually: MSFT_ScriptResource failed to execute Set-TargetResource functionality with error message: Exception calling "DownloadFile" with "2" argument(s): "The remote server returned an error: (404) Not Found." .
This tells me that the file I am attempting to download is missing (or my URI is wrong).
Another useful case for Trace-xDscConfiguration is right after you apply a configuration using Set-DscLocalConfigurationManager.
When I do this I frequently find a comment that the task will be created pending a reboot. This indicates to me that DSC is going to do absolutely nothing until I reboot that machine.
I thought I was going insane the first time nothing happened and I stumbled on this message - you don't see it if you use the -Verbose switch, only in the trace.
Get-ScheduledTask "Consistency" | Start-ScheduledTask
This will immediately re-process a configuration.
My scenario is this:
I place my configuration on a pull server.
I then configure the DSC Local Configuration Manager with the GUID of that configuration.
Then I can tweak the configuration and play with it, and not have to push it each time.
Running the consistency command allows me to 'do it now' and force a configuration to be applied, instead of waiting for my configured application window of time to pass.
Trace-xDscOperation | where { $_.EventType -eq "error" } | fl
This requires that you have the xDscDiagnostics module on your target machine. (Which if you are sorting out using DSC and applying configurations - this is necessary).
Lots of folks have blogged about it.
And it is handy with only two commands Get-xDscOperation and Trace-xDscOperation and the value add that it will enable tracing for you the first time you run in. Usability is high in this one.
Get-xDscOperation shows the job list.
Get-xDscOperation
This error you will always see the first time you apply a configuration.
If you want to know if DSC is chugging along and doing its thing you have to check the status of the consistency job:
Get-ScheduledTask "Consistency"
TaskPath TaskName State
-------- -------- -----
\Microsoft\Windows\Desired State Configurat... Consistency Running
Now, lets look at another failure to see the details.
Trace-xDscOperation | where { $_.EventType -eq "error" } | fl
There is good detail in here, you just have to find it.
[Script]MediaDownload is one of my configuration items. It is the Script Resource Provider (that is necessary context for the next)
The detail of the error is actually: MSFT_ScriptResource failed to execute Set-TargetResource functionality with error message: Exception calling "DownloadFile" with "2" argument(s): "The remote server returned an error: (404) Not Found." .
This tells me that the file I am attempting to download is missing (or my URI is wrong).
Another useful case for Trace-xDscConfiguration is right after you apply a configuration using Set-DscLocalConfigurationManager.
When I do this I frequently find a comment that the task will be created pending a reboot. This indicates to me that DSC is going to do absolutely nothing until I reboot that machine.
I thought I was going insane the first time nothing happened and I stumbled on this message - you don't see it if you use the -Verbose switch, only in the trace.
Subscribe to:
Posts (Atom)