Hi,
I know. It’s really kind of strange, because I tested the sequence of steps I needed to do the Exchange installation several times, before hand, and even documented it, and as you said, when I ran Add-WindowsFeature it didn’t force a reboot (and no, I don’t have “-reboot” on the command). Nevertheless, it seems to be good now. I’ll try to re-test later, but I’m just happy that it all seems to be working for me now.
Thanks again,
Jim
On Tue, 7/7/15, Steven Murawski steven.murawski@gmail.com wrote:
Subject: [chef] Re: Re: Re: Re: Re: Chef run stops - WMI error?
To: chef@lists.opscode.com
Cc: “o haya” ohaya@yahoo.com
Date: Tuesday, July 7, 2015, 2:18 PM
Add-WindowsFeature
shouldn’t reboot a node unless you specify -reboot.
The install of a feature may require a reboot before other
features are installed, but it shouldn’t just reboot the
box without that switch.
The output of add-windowsfeature will
include a property indicating if a reboot is
required.
Steve
Steven MurawskiCommunity Software Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com
On 7/7/2015 1:05:29
PM, o haya ohaya@yahoo.com wrote:Hi,
From more testing, it appears that the real
culprit was the Add-WindowsFeature itself rather than the
DISM. It looks like the Add-WindowsFeature forces a reboot
after it’s done by itself, and there doesn’t appear
a way to prevent that.
I am testing to confirm, but my code
originally looked like:
log something
Add-WindowsFeature
log something2
DISM
log something3
Create new scheduled task for next phase
I originally thought (wishful thinking)
that the DISM was causing the reboot, and somehow preventing
the something2 log message, but that doesn’t appear to
be the case.
I also think that for the install I’m
doing, for Exchange 2010, the DISM may not be needed… all
this time, I thought it was running "invisibly"
but now I think it was never running.
So, I’ve moved the create task before
the Add-WindowsFeature, and gotten rid of the DISM and just
got done running another test, and it works fine now…
THANKS!!
Jim
On Tue, 7/7/15, Steven Murawski wrote:
Subject: [chef] Re: Re: Re: Chef run stops
To: chef@lists.opscode.com
Cc: “o haya”
Date: Tuesday, July 7, 2015, 12:22 PM
Without any additional context, I could
only go on
the WMI exception, which was failing to
run some WMI
query.
If what you are doing with
Add-WindowsFeature or
DISM requires a reboot, the best way to
handle that is with
the reboot resource
That’ll make sure the chef-client run
finishes
cleanly. You may want to break up what
your are doing into
more discreet blocks like (warning:
pseudocode)
…* reboot
‘only when called’ # with an
action of
nothing*
powershell_script 'register scheduled
task’ # with a
guard to check if a reboot is actually
needed and notify
reboot handler to reboot* log 'stuff
1’*
powershell_script 'add windows
feature’*
log ‘stuff 2’* powershell_script
’do your dism-y
stuff’
And
have the powershell_scripts notify the
register scheduled
task powershell_script which should
determine if a reboot is
needed, configure the task and restart the
node.
If you want to do more of that in
one powershell_script block, you are
likely going to need to
add some error handling/state detection.
Regardless, if
you do add-windowsfeature by itself in a
powershell_script,
you’ll want to include a guard that
checks that the
features are installed, otherwise
it’ll run that
powershell script block every time and
report a resource
updated. Add-WindowsFeature is smart
enough to only work
when required, but the powershell_script
resource is not and
any notifies actions will be taken even if
add-windowsfeature did nothing.
Steven MurawskiCommunity Software
Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com
On
7/7/2015 9:57:19
AM, o haya wrote:Hi Steven,
I’m not sure WHICH WMI query
you’re
asking to run?
But, I have been doing some more
refactoring/testing of my recipe, and I am
coming to a
possible theory.
My recipe currently does the following in
a
powershell_script resource:
echo stuff1 to log file
Add-WindowsFeature, then
echo stuff2 to log file
DISM, then
echo stuff3 to log file
Invoke-expression to create a scheduled
task (via schtasks) for the
"next" phase of my
installation
Now, the last thing I see in my log file
is
“stuff1”, which I’ve been
ASSUMING meant that
the Add-WndowsFeature never finished (or
more clearly, that
the DISM.exe doesn’t execute).
But, from some testing, it now appears
that
after the DISM.exe executes, it is, by
itself, causing a
reboot (so Chef-client doesn’t know
that this is
happening).
I’m too new to Chef, but is it
possible
that the above sequence has a kind of race
condition, and
that the DISM.exe does execute and cause a
reboot and the
timing is such that even though there is
the "echo
stuff2" BEFORE the DISM.exe the
"stuff2"
output is getting LOST?
Thanks,
Jim
On Tue, 7/7/15, Steven Murawski wrote:
Subject: [chef] Re: Chef run stops - WMI
error?
To: chef@lists.opscode.com
Cc: “o haya”
Date: Tuesday, July 7, 2015, 10:28 AM
Can you run the same WMI
query via PowerShell or WMIC?
The WMI service error is indicating
that it thinks a system shutdown is in
progress, so there
may be some WMI corruption.
Steve
Steven MurawskiCommunity Software
Development Engineer @
ChefMicrosoft MVP - PowerShell
http://stevenmurawski.com
On
7/7/2015 12:20:04
AM, o haya wrote:Hi,
I am encountering a situation where,
intermittently (actually most of the
time)
a Chef client run
that I start using schtask is
stopping/terminating. So I
turned on debug logging on the client,
and
I see several of
these in the log:
[2015-07-07T00:59:29-04:00] DEBUG:
Re-raising exception:
WmiLite::WmiException - An error
occurred connecting to the WMI service
for
namespace
‘root/cimv2’. The namespace may
not be valid, access
may not be allowed to the WMI service, or
the WMI service
may not be available.
(in OLE method `ConnectServer’: )
OLE error code:8007045B in
SWbemLocator
A system shutdown is in progress.
HRESULT error code:0x80020009
Exception occurred.
c:/opscode/chef/embedded/l
FYI, the Chef client is on Windows 2008
R2
and here’s the Chef version info from
the log:
Logfile created on 2015-07-07 00:58:02
-0400 by logger.rb/41954
[2015-07-07T00:58:02-04:00] DEBUG:
Sleeping
for 0 seconds
[2015-07-07T00:58:06-04:00] INFO: ***
Chef
12.3.0 ***
I’ve seen some messages about
changing
some Winrm parameters for a similar
problem, but I checked
and the values in those Winrm parameters
on my system are
already way larger than the ones
mentioned
in the messages
that I’ve seen, so I’m not sure
how to get around
this problem.
Thanks,
Jim