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 <hems...@gmail.com> 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 <dkjones9...@gmail.com>
> wrote:
>
>> Thanks Todd!
>>
>> On Thu, Mar 16, 2017 at 3:36 PM, Todd Hemsell <hems...@gmail.com> 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 <dkjones9...@gmail.com>
>>> 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?
>>>>
>>>> Argggg
>>>> Dave the scapegoat
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


Reply via email to