Re: [mssms] Enabling/Disabling SUP

[Todd Hemsell]

the place to look would be that client repair check log. It list what it
checks. If it checks it I would assume it fixes it. Also might tell you in
the console on client health actions.

On Fri, Mar 17, 2017 at 8:28 AM, David Jones  wrote:

> I have found the same to be true.  But does anyone know, is it
> expected/normal behavior for the SCCM client to enable Windows Updates
> service on a computer/server that has it disabled if the SUP policy is
> enabled in the client settings?
>
> On Thu, Mar 16, 2017 at 4:26 PM, Todd Hemsell  wrote:
>
>> I have found the best approach to take when accused of something is to
>> own it.
>> Oops, yes.. I certainly is possible that there was an unintended
>> consequence of what I did. Let me go and investigate.
>>
>> Then come back to them with the names of logs, and screenshots or
>> copy/paste of the relevant lines of the logs that either makes you think it
>> wasn't you, or it was you but you found the solution on how to prevent it
>> from happening again.
>>
>> Once you lay down that for sure it wasn't you it is hard to get out of if
>> it turns out it was you.
>> Sometimes it will be you. That is just the nature of the business. Make
>> sure you find the solution on how to prevent it from happening again and
>> include that along with your confession. :)
>>
>> Doing this seems to disarm people and remove their desire to kill you
>> over it. If you make them feel like (emotion) that you really care and are
>> sincerely trying to help, most will lay off of you.
>>
>>
>> On Thu, Mar 16, 2017 at 2:49 PM, David Jones 
>> wrote:
>>
>>> Thanks Todd!
>>>
>>> On Thu, Mar 16, 2017 at 3:36 PM, Todd Hemsell  wrote:
>>>
 For the exchange servers, look in the event logs, specifically the
 setup log. It will be in there.
 SCCM can install something and not reboot, THEN the AU agent on the
 server kicks in, sees it needs a reboot, and bounces the machine.\

 For the WSUS, look in the C:\Windows\WindowsUpdate.log for URL's
 You will see their server and possibly yours.

 What you find there should give you hints where to go next.

 On Thu, Mar 16, 2017 at 12:57 PM, David Jones 
 wrote:

> I hope someone can give me an answer or refer me to something by
> tomorrow.
>
> situation:
> 1. SCCM CB 1606hf2, 1 Primary only, Server 2012R2. Only using it for
> Apps/Packages/Inventory/Software Center.  Only other server is a
> 2012R2 DP.
> 2. SUP Client Setting set to No and SCCM has no SUP role installed.
> 2. Decide to use SUP. Set Client Setting to Yes. Install WSUS, Install
> SUP role on Primary, no SSL. Configure SUP/WSUS settings. Create NO
> groups or packages yet. this is all. A list of updates populates all
> updates.
> 3. Sits this way for about 5 days. Nothing else is done. In the
> background, a WSUS is still running in production and it's GP is still
> active on the domain. Can't get numbers in the All Updates for
> required/installed because of the GP pointing to the WSUS server.
>
> Question 1. Is this a safe scenario so far? Could I have something in
> place at this point that would interfere with the WSUS in production? The
> only thing I could think of is the local GP for pointing to the SCCM 
> server
> that should be overridden by the domain policy pointing to the WSUS 
> server.
> That should create no problem for the WSUS in production as it's GP has
> precedence.
>
> 4. WSUS folks claiming I have done something to kill some computers
> from getting WSUS updates. Remove the SUP role. Leave the SUP Client
> Setting at Yes. Remove WSUS from SCCM server. Reinstall the WSUS role on
> the server this time putting it in SQL 2014 with SCCM instead of using 
> WID.
> 5. Exchange servers folks claim that has caused their servers to
> reboot in the middle of the day. Say is may be because they had the 
> Windows
> Updates server disabled and the SCCM client enabled it and caused mid day
> reboots.
>
> Question 2:  Is there any kind of way at all this could happen?
>
> Ar
> Dave the scapegoat
>
>
>
>


>>>
>>>
>>
>>
>
>

Re: [mssms] Enabling/Disabling SUP

[Adam Juelich]

That I'm unsure of.  I know it needs it to be enabled to function, so I
would say 'yes.'

On Fri, Mar 17, 2017 at 9:49 AM, David Jones  wrote:

> Actually, yes I meant the Windows Updates service on the Exchange servers.
> My understanding is it wasn't disabled by GP, just manually disabled.
>
> So could the ConfigMgr Client re-enable a manually disabled Windows
> Updates service on a client if SUP was set to yes in the client settings?
>
> On Fri, Mar 17, 2017 at 9:49 AM, Adam Juelich  wrote:
>
>> The actual Service?  That shouldn't be disabled.
>>
>> The only thing you want to disable in Group Policy is 'Automatic Updates.'
>>
>> The service is still leveraged for WU through the ConfigMgr Client.
>>
>> On Fri, Mar 17, 2017 at 8:28 AM, David Jones 
>> wrote:
>>
>>> I have found the same to be true.  But does anyone know, is it
>>> expected/normal behavior for the SCCM client to enable Windows Updates
>>> service on a computer/server that has it disabled if the SUP policy is
>>> enabled in the client settings?
>>>
>>> On Thu, Mar 16, 2017 at 4:26 PM, Todd Hemsell  wrote:
>>>
 I have found the best approach to take when accused of something is to
 own it.
 Oops, yes.. I certainly is possible that there was an unintended
 consequence of what I did. Let me go and investigate.

 Then come back to them with the names of logs, and screenshots or
 copy/paste of the relevant lines of the logs that either makes you think it
 wasn't you, or it was you but you found the solution on how to prevent it
 from happening again.

 Once you lay down that for sure it wasn't you it is hard to get out of
 if it turns out it was you.
 Sometimes it will be you. That is just the nature of the business. Make
 sure you find the solution on how to prevent it from happening again and
 include that along with your confession. :)

 Doing this seems to disarm people and remove their desire to kill you
 over it. If you make them feel like (emotion) that you really care and are
 sincerely trying to help, most will lay off of you.


 On Thu, Mar 16, 2017 at 2:49 PM, David Jones 
 wrote:

> Thanks Todd!
>
> On Thu, Mar 16, 2017 at 3:36 PM, Todd Hemsell 
> wrote:
>
>> For the exchange servers, look in the event logs, specifically the
>> setup log. It will be in there.
>> SCCM can install something and not reboot, THEN the AU agent on the
>> server kicks in, sees it needs a reboot, and bounces the machine.\
>>
>> For the WSUS, look in the C:\Windows\WindowsUpdate.log for URL's
>> You will see their server and possibly yours.
>>
>> What you find there should give you hints where to go next.
>>
>> On Thu, Mar 16, 2017 at 12:57 PM, David Jones 
>> wrote:
>>
>>> I hope someone can give me an answer or refer me to something by
>>> tomorrow.
>>>
>>> situation:
>>> 1. SCCM CB 1606hf2, 1 Primary only, Server 2012R2. Only using it for
>>> Apps/Packages/Inventory/Software Center.  Only other server is a
>>> 2012R2 DP.
>>> 2. SUP Client Setting set to No and SCCM has no SUP role installed.
>>> 2. Decide to use SUP. Set Client Setting to Yes. Install WSUS,
>>> Install SUP role on Primary, no SSL. Configure SUP/WSUS settings. 
>>> Create NO
>>> groups or packages yet. this is all. A list of updates populates all
>>> updates.
>>> 3. Sits this way for about 5 days. Nothing else is done. In the
>>> background, a WSUS is still running in production and it's GP is still
>>> active on the domain. Can't get numbers in the All Updates for
>>> required/installed because of the GP pointing to the WSUS server.
>>>
>>> Question 1. Is this a safe scenario so far? Could I have something
>>> in place at this point that would interfere with the WSUS in production?
>>> The only thing I could think of is the local GP for pointing to the SCCM
>>> server that should be overridden by the domain policy pointing to the 
>>> WSUS
>>> server. That should create no problem for the WSUS in production as 
>>> it's GP
>>> has precedence.
>>>
>>> 4. WSUS folks claiming I have done something to kill some computers
>>> from getting WSUS updates. Remove the SUP role. Leave the SUP Client
>>> Setting at Yes. Remove WSUS from SCCM server. Reinstall the WSUS role on
>>> the server this time putting it in SQL 2014 with SCCM instead of using 
>>> WID.
>>> 5. Exchange servers folks claim that has caused their servers to
>>> reboot in the middle of the day. Say is may be because they had the 
>>> Windows
>>> Updates server disabled and the SCCM client enabled it and caused mid 
>>> day
>>> reboots.
>>>
>>> Question 2:  Is 

Re: [mssms] Enabling/Disabling SUP

[David Jones]

Actually, yes I meant the Windows Updates service on the Exchange servers.
My understanding is it wasn't disabled by GP, just manually disabled.

So could the ConfigMgr Client re-enable a manually disabled Windows Updates
service on a client if SUP was set to yes in the client settings?

On Fri, Mar 17, 2017 at 9:49 AM, Adam Juelich  wrote:

> The actual Service?  That shouldn't be disabled.
>
> The only thing you want to disable in Group Policy is 'Automatic Updates.'
>
> The service is still leveraged for WU through the ConfigMgr Client.
>
> On Fri, Mar 17, 2017 at 8:28 AM, David Jones 
> wrote:
>
>> I have found the same to be true.  But does anyone know, is it
>> expected/normal behavior for the SCCM client to enable Windows Updates
>> service on a computer/server that has it disabled if the SUP policy is
>> enabled in the client settings?
>>
>> On Thu, Mar 16, 2017 at 4:26 PM, Todd Hemsell  wrote:
>>
>>> I have found the best approach to take when accused of something is to
>>> own it.
>>> Oops, yes.. I certainly is possible that there was an unintended
>>> consequence of what I did. Let me go and investigate.
>>>
>>> Then come back to them with the names of logs, and screenshots or
>>> copy/paste of the relevant lines of the logs that either makes you think it
>>> wasn't you, or it was you but you found the solution on how to prevent it
>>> from happening again.
>>>
>>> Once you lay down that for sure it wasn't you it is hard to get out of
>>> if it turns out it was you.
>>> Sometimes it will be you. That is just the nature of the business. Make
>>> sure you find the solution on how to prevent it from happening again and
>>> include that along with your confession. :)
>>>
>>> Doing this seems to disarm people and remove their desire to kill you
>>> over it. If you make them feel like (emotion) that you really care and are
>>> sincerely trying to help, most will lay off of you.
>>>
>>>
>>> On Thu, Mar 16, 2017 at 2:49 PM, David Jones 
>>> wrote:
>>>
 Thanks Todd!

 On Thu, Mar 16, 2017 at 3:36 PM, Todd Hemsell 
 wrote:

> For the exchange servers, look in the event logs, specifically the
> setup log. It will be in there.
> SCCM can install something and not reboot, THEN the AU agent on the
> server kicks in, sees it needs a reboot, and bounces the machine.\
>
> For the WSUS, look in the C:\Windows\WindowsUpdate.log for URL's
> You will see their server and possibly yours.
>
> What you find there should give you hints where to go next.
>
> On Thu, Mar 16, 2017 at 12:57 PM, David Jones 
> wrote:
>
>> I hope someone can give me an answer or refer me to something by
>> tomorrow.
>>
>> situation:
>> 1. SCCM CB 1606hf2, 1 Primary only, Server 2012R2. Only using it for
>> Apps/Packages/Inventory/Software Center.  Only other server is a
>> 2012R2 DP.
>> 2. SUP Client Setting set to No and SCCM has no SUP role installed.
>> 2. Decide to use SUP. Set Client Setting to Yes. Install WSUS,
>> Install SUP role on Primary, no SSL. Configure SUP/WSUS settings. Create 
>> NO
>> groups or packages yet. this is all. A list of updates populates all
>> updates.
>> 3. Sits this way for about 5 days. Nothing else is done. In the
>> background, a WSUS is still running in production and it's GP is still
>> active on the domain. Can't get numbers in the All Updates for
>> required/installed because of the GP pointing to the WSUS server.
>>
>> Question 1. Is this a safe scenario so far? Could I have something in
>> place at this point that would interfere with the WSUS in production? The
>> only thing I could think of is the local GP for pointing to the SCCM 
>> server
>> that should be overridden by the domain policy pointing to the WSUS 
>> server.
>> That should create no problem for the WSUS in production as it's GP has
>> precedence.
>>
>> 4. WSUS folks claiming I have done something to kill some computers
>> from getting WSUS updates. Remove the SUP role. Leave the SUP Client
>> Setting at Yes. Remove WSUS from SCCM server. Reinstall the WSUS role on
>> the server this time putting it in SQL 2014 with SCCM instead of using 
>> WID.
>> 5. Exchange servers folks claim that has caused their servers to
>> reboot in the middle of the day. Say is may be because they had the 
>> Windows
>> Updates server disabled and the SCCM client enabled it and caused mid day
>> reboots.
>>
>> Question 2:  Is there any kind of way at all this could happen?
>>
>> Ar
>> Dave the scapegoat
>>
>>
>>
>>
>
>


>>>
>>>
>>
>>
>
>

Re: [mssms] Enabling/Disabling SUP

[Adam Juelich]

The actual Service?  That shouldn't be disabled.

The only thing you want to disable in Group Policy is 'Automatic Updates.'

The service is still leveraged for WU through the ConfigMgr Client.

On Fri, Mar 17, 2017 at 8:28 AM, David Jones  wrote:

> I have found the same to be true.  But does anyone know, is it
> expected/normal behavior for the SCCM client to enable Windows Updates
> service on a computer/server that has it disabled if the SUP policy is
> enabled in the client settings?
>
> On Thu, Mar 16, 2017 at 4:26 PM, Todd Hemsell  wrote:
>
>> I have found the best approach to take when accused of something is to
>> own it.
>> Oops, yes.. I certainly is possible that there was an unintended
>> consequence of what I did. Let me go and investigate.
>>
>> Then come back to them with the names of logs, and screenshots or
>> copy/paste of the relevant lines of the logs that either makes you think it
>> wasn't you, or it was you but you found the solution on how to prevent it
>> from happening again.
>>
>> Once you lay down that for sure it wasn't you it is hard to get out of if
>> it turns out it was you.
>> Sometimes it will be you. That is just the nature of the business. Make
>> sure you find the solution on how to prevent it from happening again and
>> include that along with your confession. :)
>>
>> Doing this seems to disarm people and remove their desire to kill you
>> over it. If you make them feel like (emotion) that you really care and are
>> sincerely trying to help, most will lay off of you.
>>
>>
>> On Thu, Mar 16, 2017 at 2:49 PM, David Jones 
>> wrote:
>>
>>> Thanks Todd!
>>>
>>> On Thu, Mar 16, 2017 at 3:36 PM, Todd Hemsell  wrote:
>>>
 For the exchange servers, look in the event logs, specifically the
 setup log. It will be in there.
 SCCM can install something and not reboot, THEN the AU agent on the
 server kicks in, sees it needs a reboot, and bounces the machine.\

 For the WSUS, look in the C:\Windows\WindowsUpdate.log for URL's
 You will see their server and possibly yours.

 What you find there should give you hints where to go next.

 On Thu, Mar 16, 2017 at 12:57 PM, David Jones 
 wrote:

> I hope someone can give me an answer or refer me to something by
> tomorrow.
>
> situation:
> 1. SCCM CB 1606hf2, 1 Primary only, Server 2012R2. Only using it for
> Apps/Packages/Inventory/Software Center.  Only other server is a
> 2012R2 DP.
> 2. SUP Client Setting set to No and SCCM has no SUP role installed.
> 2. Decide to use SUP. Set Client Setting to Yes. Install WSUS, Install
> SUP role on Primary, no SSL. Configure SUP/WSUS settings. Create NO
> groups or packages yet. this is all. A list of updates populates all
> updates.
> 3. Sits this way for about 5 days. Nothing else is done. In the
> background, a WSUS is still running in production and it's GP is still
> active on the domain. Can't get numbers in the All Updates for
> required/installed because of the GP pointing to the WSUS server.
>
> Question 1. Is this a safe scenario so far? Could I have something in
> place at this point that would interfere with the WSUS in production? The
> only thing I could think of is the local GP for pointing to the SCCM 
> server
> that should be overridden by the domain policy pointing to the WSUS 
> server.
> That should create no problem for the WSUS in production as it's GP has
> precedence.
>
> 4. WSUS folks claiming I have done something to kill some computers
> from getting WSUS updates. Remove the SUP role. Leave the SUP Client
> Setting at Yes. Remove WSUS from SCCM server. Reinstall the WSUS role on
> the server this time putting it in SQL 2014 with SCCM instead of using 
> WID.
> 5. Exchange servers folks claim that has caused their servers to
> reboot in the middle of the day. Say is may be because they had the 
> Windows
> Updates server disabled and the SCCM client enabled it and caused mid day
> reboots.
>
> Question 2:  Is there any kind of way at all this could happen?
>
> Ar
> Dave the scapegoat
>
>
>
>


>>>
>>>
>>
>>
>
>

Re: [mssms] Enabling/Disabling SUP

[David Jones]

I have found the same to be true.  But does anyone know, is it
expected/normal behavior for the SCCM client to enable Windows Updates
service on a computer/server that has it disabled if the SUP policy is
enabled in the client settings?

On Thu, Mar 16, 2017 at 4:26 PM, Todd Hemsell  wrote:

> I have found the best approach to take when accused of something is to own
> it.
> Oops, yes.. I certainly is possible that there was an unintended
> consequence of what I did. Let me go and investigate.
>
> Then come back to them with the names of logs, and screenshots or
> copy/paste of the relevant lines of the logs that either makes you think it
> wasn't you, or it was you but you found the solution on how to prevent it
> from happening again.
>
> Once you lay down that for sure it wasn't you it is hard to get out of if
> it turns out it was you.
> Sometimes it will be you. That is just the nature of the business. Make
> sure you find the solution on how to prevent it from happening again and
> include that along with your confession. :)
>
> Doing this seems to disarm people and remove their desire to kill you over
> it. If you make them feel like (emotion) that you really care and are
> sincerely trying to help, most will lay off of you.
>
>
> On Thu, Mar 16, 2017 at 2:49 PM, David Jones 
> wrote:
>
>> Thanks Todd!
>>
>> On Thu, Mar 16, 2017 at 3:36 PM, Todd Hemsell  wrote:
>>
>>> For the exchange servers, look in the event logs, specifically the setup
>>> log. It will be in there.
>>> SCCM can install something and not reboot, THEN the AU agent on the
>>> server kicks in, sees it needs a reboot, and bounces the machine.\
>>>
>>> For the WSUS, look in the C:\Windows\WindowsUpdate.log for URL's
>>> You will see their server and possibly yours.
>>>
>>> What you find there should give you hints where to go next.
>>>
>>> On Thu, Mar 16, 2017 at 12:57 PM, David Jones 
>>> wrote:
>>>
 I hope someone can give me an answer or refer me to something by
 tomorrow.

 situation:
 1. SCCM CB 1606hf2, 1 Primary only, Server 2012R2. Only using it for
 Apps/Packages/Inventory/Software Center.  Only other server is a
 2012R2 DP.
 2. SUP Client Setting set to No and SCCM has no SUP role installed.
 2. Decide to use SUP. Set Client Setting to Yes. Install WSUS, Install
 SUP role on Primary, no SSL. Configure SUP/WSUS settings. Create NO
 groups or packages yet. this is all. A list of updates populates all
 updates.
 3. Sits this way for about 5 days. Nothing else is done. In the
 background, a WSUS is still running in production and it's GP is still
 active on the domain. Can't get numbers in the All Updates for
 required/installed because of the GP pointing to the WSUS server.

 Question 1. Is this a safe scenario so far? Could I have something in
 place at this point that would interfere with the WSUS in production? The
 only thing I could think of is the local GP for pointing to the SCCM server
 that should be overridden by the domain policy pointing to the WSUS server.
 That should create no problem for the WSUS in production as it's GP has
 precedence.

 4. WSUS folks claiming I have done something to kill some computers
 from getting WSUS updates. Remove the SUP role. Leave the SUP Client
 Setting at Yes. Remove WSUS from SCCM server. Reinstall the WSUS role on
 the server this time putting it in SQL 2014 with SCCM instead of using WID.
 5. Exchange servers folks claim that has caused their servers to reboot
 in the middle of the day. Say is may be because they had the Windows
 Updates server disabled and the SCCM client enabled it and caused mid day
 reboots.

 Question 2:  Is there any kind of way at all this could happen?

 Ar
 Dave the scapegoat




>>>
>>>
>>
>>
>
>

Re: [mssms] Enabling/Disabling SUP

[Todd Hemsell]

I have found the best approach to take when accused of something is to own
it.
Oops, yes.. I certainly is possible that there was an unintended
consequence of what I did. Let me go and investigate.

Then come back to them with the names of logs, and screenshots or
copy/paste of the relevant lines of the logs that either makes you think it
wasn't you, or it was you but you found the solution on how to prevent it
from happening again.

Once you lay down that for sure it wasn't you it is hard to get out of if
it turns out it was you.
Sometimes it will be you. That is just the nature of the business. Make
sure you find the solution on how to prevent it from happening again and
include that along with your confession. :)

Doing this seems to disarm people and remove their desire to kill you over
it. If you make them feel like (emotion) that you really care and are
sincerely trying to help, most will lay off of you.


On Thu, Mar 16, 2017 at 2:49 PM, David Jones  wrote:

> Thanks Todd!
>
> On Thu, Mar 16, 2017 at 3:36 PM, Todd Hemsell  wrote:
>
>> For the exchange servers, look in the event logs, specifically the setup
>> log. It will be in there.
>> SCCM can install something and not reboot, THEN the AU agent on the
>> server kicks in, sees it needs a reboot, and bounces the machine.\
>>
>> For the WSUS, look in the C:\Windows\WindowsUpdate.log for URL's
>> You will see their server and possibly yours.
>>
>> What you find there should give you hints where to go next.
>>
>> On Thu, Mar 16, 2017 at 12:57 PM, David Jones 
>> wrote:
>>
>>> I hope someone can give me an answer or refer me to something by
>>> tomorrow.
>>>
>>> situation:
>>> 1. SCCM CB 1606hf2, 1 Primary only, Server 2012R2. Only using it for
>>> Apps/Packages/Inventory/Software Center.  Only other server is a 2012R2
>>> DP.
>>> 2. SUP Client Setting set to No and SCCM has no SUP role installed.
>>> 2. Decide to use SUP. Set Client Setting to Yes. Install WSUS, Install
>>> SUP role on Primary, no SSL. Configure SUP/WSUS settings. Create NO
>>> groups or packages yet. this is all. A list of updates populates all
>>> updates.
>>> 3. Sits this way for about 5 days. Nothing else is done. In the
>>> background, a WSUS is still running in production and it's GP is still
>>> active on the domain. Can't get numbers in the All Updates for
>>> required/installed because of the GP pointing to the WSUS server.
>>>
>>> Question 1. Is this a safe scenario so far? Could I have something in
>>> place at this point that would interfere with the WSUS in production? The
>>> only thing I could think of is the local GP for pointing to the SCCM server
>>> that should be overridden by the domain policy pointing to the WSUS server.
>>> That should create no problem for the WSUS in production as it's GP has
>>> precedence.
>>>
>>> 4. WSUS folks claiming I have done something to kill some computers from
>>> getting WSUS updates. Remove the SUP role. Leave the SUP Client Setting at
>>> Yes. Remove WSUS from SCCM server. Reinstall the WSUS role on the server
>>> this time putting it in SQL 2014 with SCCM instead of using WID.
>>> 5. Exchange servers folks claim that has caused their servers to reboot
>>> in the middle of the day. Say is may be because they had the Windows
>>> Updates server disabled and the SCCM client enabled it and caused mid day
>>> reboots.
>>>
>>> Question 2:  Is there any kind of way at all this could happen?
>>>
>>> Ar
>>> Dave the scapegoat
>>>
>>>
>>>
>>>
>>
>>
>
>

Re: [mssms] Enabling/Disabling SUP

[David Jones]

Thanks Todd!

On Thu, Mar 16, 2017 at 3:36 PM, Todd Hemsell  wrote:

> For the exchange servers, look in the event logs, specifically the setup
> log. It will be in there.
> SCCM can install something and not reboot, THEN the AU agent on the server
> kicks in, sees it needs a reboot, and bounces the machine.\
>
> For the WSUS, look in the C:\Windows\WindowsUpdate.log for URL's
> You will see their server and possibly yours.
>
> What you find there should give you hints where to go next.
>
> On Thu, Mar 16, 2017 at 12:57 PM, David Jones 
> wrote:
>
>> I hope someone can give me an answer or refer me to something by
>> tomorrow.
>>
>> situation:
>> 1. SCCM CB 1606hf2, 1 Primary only, Server 2012R2. Only using it for
>> Apps/Packages/Inventory/Software Center.  Only other server is a 2012R2
>> DP.
>> 2. SUP Client Setting set to No and SCCM has no SUP role installed.
>> 2. Decide to use SUP. Set Client Setting to Yes. Install WSUS, Install
>> SUP role on Primary, no SSL. Configure SUP/WSUS settings. Create NO
>> groups or packages yet. this is all. A list of updates populates all
>> updates.
>> 3. Sits this way for about 5 days. Nothing else is done. In the
>> background, a WSUS is still running in production and it's GP is still
>> active on the domain. Can't get numbers in the All Updates for
>> required/installed because of the GP pointing to the WSUS server.
>>
>> Question 1. Is this a safe scenario so far? Could I have something in
>> place at this point that would interfere with the WSUS in production? The
>> only thing I could think of is the local GP for pointing to the SCCM server
>> that should be overridden by the domain policy pointing to the WSUS server.
>> That should create no problem for the WSUS in production as it's GP has
>> precedence.
>>
>> 4. WSUS folks claiming I have done something to kill some computers from
>> getting WSUS updates. Remove the SUP role. Leave the SUP Client Setting at
>> Yes. Remove WSUS from SCCM server. Reinstall the WSUS role on the server
>> this time putting it in SQL 2014 with SCCM instead of using WID.
>> 5. Exchange servers folks claim that has caused their servers to reboot
>> in the middle of the day. Say is may be because they had the Windows
>> Updates server disabled and the SCCM client enabled it and caused mid day
>> reboots.
>>
>> Question 2:  Is there any kind of way at all this could happen?
>>
>> Ar
>> Dave the scapegoat
>>
>>
>>
>>
>
>

Re: [mssms] Enabling/Disabling SUP

[Todd Hemsell]

For the exchange servers, look in the event logs, specifically the setup
log. It will be in there.
SCCM can install something and not reboot, THEN the AU agent on the server
kicks in, sees it needs a reboot, and bounces the machine.\

For the WSUS, look in the C:\Windows\WindowsUpdate.log for URL's
You will see their server and possibly yours.

What you find there should give you hints where to go next.

On Thu, Mar 16, 2017 at 12:57 PM, David Jones  wrote:

> I hope someone can give me an answer or refer me to something by tomorrow.
>
> situation:
> 1. SCCM CB 1606hf2, 1 Primary only, Server 2012R2. Only using it for
> Apps/Packages/Inventory/Software Center.  Only other server is a 2012R2
> DP.
> 2. SUP Client Setting set to No and SCCM has no SUP role installed.
> 2. Decide to use SUP. Set Client Setting to Yes. Install WSUS, Install SUP
> role on Primary, no SSL. Configure SUP/WSUS settings. Create NO groups or
> packages yet. this is all. A list of updates populates all updates.
> 3. Sits this way for about 5 days. Nothing else is done. In the
> background, a WSUS is still running in production and it's GP is still
> active on the domain. Can't get numbers in the All Updates for
> required/installed because of the GP pointing to the WSUS server.
>
> Question 1. Is this a safe scenario so far? Could I have something in
> place at this point that would interfere with the WSUS in production? The
> only thing I could think of is the local GP for pointing to the SCCM server
> that should be overridden by the domain policy pointing to the WSUS server.
> That should create no problem for the WSUS in production as it's GP has
> precedence.
>
> 4. WSUS folks claiming I have done something to kill some computers from
> getting WSUS updates. Remove the SUP role. Leave the SUP Client Setting at
> Yes. Remove WSUS from SCCM server. Reinstall the WSUS role on the server
> this time putting it in SQL 2014 with SCCM instead of using WID.
> 5. Exchange servers folks claim that has caused their servers to reboot in
> the middle of the day. Say is may be because they had the Windows Updates
> server disabled and the SCCM client enabled it and caused mid day reboots.
>
> Question 2:  Is there any kind of way at all this could happen?
>
> Ar
> Dave the scapegoat
>
>
>
>