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 >>> >>> >>> >>> >> >> > >
