Jump to content


deletejunkemail

Established Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by deletejunkemail

  1. MW will never be greater than 24hrs? Can you elaborate as i've seen forums that say they give their users 2 weeks time to install software updates. I'm sure what you are saying is right but i'm just unclear myself being a noob with SCCM.
  2. ZeZe I appreciate your input! I discovered that a deployed software update has a User Experience option to never restart - Of course, this would only be geared towards special groups that understand the risk of not ever restarting and applying any necessary updates Another option, as an example, is to have updates available on Day 1 (could be any designated day of the month) and have a maintenance window for 20 days (or whatever number of days). This would allow a user to install the updates on their timeline up till day 20 where the forced install and restart would occur. - Pros: Gives users more time to be compliant - Cons: Most users would not remember or voluntarily install updates which would lead to the deadline being forced and internal customers being upset. So again, this would be geared toward specific users.
  3. Hi Windows Noob Folks! In SCCM, the client setting allows a maximum of 24hrs for a user to suppress a reboot. Are there ways, methods, best practices for a user to surpress/delay a reboot? - Example: Lets say I have an engineering group that may have already started a task that could take 5+- days to finish and a reboot would just destroy their work. Only answer i've found were to have those types of users update their machines themselves but that may not be an option. Regular computer users such as a normal phone support, receptionist, non critical computer use folks would be ok with the 24hrs or less reboot.
  4. Wow! I'm privileged that you have responded to my post! Love your website as it has helped me more than any resource i've found so far! I appreciate the response which i understand now how things flow and that the MDT Toolkit Package and MDT Settings can be reused by other Task Sequences. Since there is only one folder for scripts that contain the ...\Scripts\UDIWizard_Config.xml, how would I make sure that my next Task Sequence's UDIWizard_Config doesnt overwrite or how do i know which UDI File is for my next Task Sequece?
  5. Hello Folks, Long time Windows Noob fan, first time poster... I have a question about a Task Sequence in SCCM with MDT... So when creating a TS via MDT, you'll have that nice wizard that helps you out and I could not find anything that would define when to create a new XYZ Package and when to reuse it or not reuse it in another SCCM MDT Task Sequence... Create MDT Task Sequence > Boot Image Step > you have a choice to use an existing one or create a new one... Since I only have the stock SCCM Boot images, i do want to make an MDT boot image for x86 and x64... - Can I use these MDT Boot Images for another TS, if yes, when would i want to create another set of MDT Boot Images x86 and x64? Create MDT Task Sequence > MDT Package Step > you have a choice to use an existing or create a new one. When you create a new one, the folders at the given UNC Path look like as if it is a new deployment share which you would use for WorkBench. - Can I use this MDT Package for another TS, if yes, when would i want to create another set of MDT Packages? Also, what is the best practices for naming convention or organization? Create MDT Task Sequence > CustomSettings.ini Step > again, you have a choice to use an existing or create a new one. Since i dont have one, i'd create a new one but when would you want to reuse it and when would you want to create a brand new one? For all 3, i feel like if i make a new anything, i should make a new folder though i'm not quite sure what the best folder plan is for organization would be. Thank you for any help, i really do appreciate it!
×
×
  • 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.