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