Jump to content


Search the Community

Showing results for tags 'Maintenance Windows'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Cloud
    • Azure
    • Microsoft Intune
    • Office 365
    • Windows 365
  • General Stuff
    • General Chat
    • Events
    • Site News
    • Official Forum Supporters
    • Windows News
    • Suggestion box
    • Jobs
  • MDT, SMS, SCCM, Current Branch &Technical Preview
    • How do I ?
    • Microsoft Deployment Toolkit (MDT)
    • SMS 2003
    • Configuration Manager 2007
    • Configuration Manager 2012
    • System Center Configuration Manager (Current Branch)
    • Packaging
    • scripting
    • Endpoint Protection
  • Windows Client
    • how do I ?
    • Windows 10
    • Windows 8
    • Windows 7
    • Windows Vista
    • Windows XP
    • windows screenshots
  • Windows Server
    • Windows Server General
    • Active Directory
    • Microsoft SQL Server
    • System Center Operations Manager
    • KMS
    • Windows Deployment Services
    • NAP
    • Failover Clustering
    • PKI
    • Hyper V
    • Exchange
    • IIS/apache/web server
    • System Center Data Protection Manager
    • System Center Service Manager
    • System Center App Controller
    • System Center Virtual Machine Manager
    • System Center Orchestrator
    • Lync
    • Application Virtualization
    • Sharepoint
    • WSUS

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests

Found 6 results

  1. We had a major SCCM issue a few weeks back caused by a hardware failure leading to database replication failures. This was "resolved" by manually syncing and rebuilding a few of the secondary site servers but since then we're having one major issue that we cannot track down or even have anything that points to what the cause could be. Not a single PC is receiving their collection based maintenance windows. They only seem to be getting their "business hours" window which is defined by the times in the software center. What we have tried: Creating new collection and applying the maintenance window times Verified maintenance windows are actually set on the collection via powershell Resetting the times for the maintenance window on the already existing collection Deleting systems from SCCM and having them be re-detected and repopulate in SCCM Uninstalling/Reinstalling SCCM client on workstation Running triggers Checked as many logs on the clients and server as I could think of Reset machine policy Reimaging computer None of these have had any changes or given me any indication on what is failing. If I run the report "Maintenance windows available to a specified client" it shows the correct information, but the PCs themselves don't seem to be receiving the information for what the system should be seeing. It doesn't matter which primary/secondary site server, all clients seem to be affected. The only thing I see in the policy for CCM_ServiceWindow have ServiceWindowType = 6, none that are ServiceWindowType = 1 which is what they should be coming from the collection settings. It just seems this all goes back to database replication issues, I just don't know what it could be. Once the replication link issues were fixed I had to redeploy all DCM baselines as well as the Client policy for enabling SCEP. So I created a clone of our default client policy and deployed that to a newly created collection with a custom maintenance window, but still nothing on the workstations. Since you don't actually deploy the default client settings I'm not sure if those are being applied properly. I'm missing something, I just don't know what it is. I don't even really know if maintenance windows not applying is the issue or a symptom of a different issue that if that is fixed the maintenance windows will start working. But that's just an idea, I have no way to really prove that. We're running SCCM 2012 R2 version 5.00.8239.1000 with a CAS, 3 Primary sites, and 17 Secondary sites. We were previously running version 5.00.7958.1000 but updated earlier this year. This environment had been functioning (more or less) properly for over a year prior to the database replication issues. Any advice would be greatly appreciated. I'm sure the advice will be to contact Microsoft, and I'd love to but our company doesn't really let us do that as Microsoft support is handled by the server team who doesn't actually have much knowledge about using SCCM itself so if that's what needs to be done I'll figure that when it happens but I'd like to be able to fix it without them. Thank you,
  2. Hello, I'm having an issue with some computer. These computer have maintenance windows. When looking with Client Center for Configuration Manager, I see my maintenance window. Also, in the servicewindowmanager.log, I see my maintenance window for all deployment. The window is 8h00pm to 5h00am, everyday. I have users calling saying they had to restart there computer in the middle of the day because of updates. When looking at updateshandler.log and wuahandler.log, I clearly see that the update have scanned at 8h34 this morning, installed at 8h45 and rebooted at 9h13. I've checked the software updates deployment and both checkbox for "installed outside maintenance window" are disabled. The deadline for the installation was yesterday at 7h00am. The computer was probably off during the maintenance window, but that should simply reschedule the update for the next maintenance window, no? Someone know what's going on? Thank you
  3. Hello everyone, I found a bug with the maintenance windows and reading on the web, it seems it existed in SCCM 07 (MS says it was by design) and now, it's has flooded my company. Here's the deal: Let's say you have a computer named ABC. It's a new computer, you deploy it via task sequence and it get into the "all system" collection. You then create a new collection, let's call it "MW-A". You then add ABC to MW-A. Then, you add a maintenance windows to MW-A, let's say monday 2:00-3:00 am. The computer get the MW (showned in policyspy and servicewindowmanagement.log). Here, everything is fine. Then you create a new collection, let's call it "MW-B". You add ABC to the this new collection. Then, you add a new maintenance windows to MW-B, let's say tuesday 2:00-3:00 am. Now, the computer have two maintenance windows. Here, still no problem. Then, you remove the computer from MW-A. You woud normally thing that the computer now has only 1 maintenance windows, from MW-B which is on tuesday, but no, it has kept the maintenance windows from MW-A. If you do a policyspy check or servicewindowsmagament.log check, you'll see it's still there even after a policy refresh. To remove the maintenance windows from the computer, you have to first remove the mw from the collection, wait for refresh, remove the computer from the collection then put back the mw on the collection. Microsoft says it work as design in 2007. Now, the problem is that we didn't knew that. Because of that, I have system with like 11 maintenance windows instead of 1. Even worst, the report from SCCM to get the maintenance windows on one computer is only checking what is attributed from the collection, not what is left on the computer. Since SCCM 2012 was used in prod when testing, all my computers are affected with MW that doesn't exist anymore (a check in the database shows no entry with these IDs). Does anyone know a way to fix that beside going one computer at a time with policyspy and deleting them?
  4. I am new to SCCM and have built a test lab to learn the product. So far everything has been good, but I am running into an issue where my clients are not respecting the defined maintenance window. As far as I can tell, the device is not a member of any other collections with additional windows defined. The deployment is not configured to allow installations outside the window after the deadline is reached, so I am not sure what is allowing the clients to pull the updates outside the window. Some advice would be greatly appreciated!
  5. Anyone have any good information on how Max run time is calculated for SCCM 2012 software update deployments? Last month i ran into issues deploying updates, and had to manually kick them off, because the max run times exceeded the Maintenance window. Updates stuck at status of "Past due - will be installed" I know i can select ignore maintenance window on deadline, but wanted to ensure updates will not install/reboot outside specified maintenance windows. I would also like to minimize the duration of the maintenance windows to just a little more than the required time for the patches and reboots. Servers are missing a lot of patches, don't think it will be an issue once we get them on a normal update cycle. Thanks
  6. A few questions on maintenance windows for SCCM 2007 collections. I have created a Parent collection that finds all of the servers I need to work with. I then have created child collections that feed off of the parent and split them based on other selections like so. Servers I Manage - (Parent) Domain Controllers - (Child)Windows 2008 - (Child)Windows 2003 - (Child)SQL Servers - (Child)Misc Servers - (Child) Now, if I set a maintenance window on the Parent Collection (Servers I Manager) and then deploy a package or update to the Child Collection (Windows 2008). The server that resides in both collections should not see the maintenance window from the parent collection as I am deploying to the child which has no maintenance window. I have read that "Maintenance windows are not inherited by subcollections." and the above would be true as there is no inheritance, but I've seen some discussion in that because the server itself resides in both collections, it will take the maintenance window from the Parent (Servers I Manage). Is this True? Thank you for any and all of your thoughts Regards, Yarrokon
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.