Jump to content


robemann83

Established Members
  • Posts

    3
  • Joined

  • Last visited

robemann83's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hi All, Hoping someone can help point me in the right direction. I am replacing old 2008 R2 MP/DPs with new 2016 Servers. The old servers have custom shares on the root of the DP Drive(TOOLS$ for example). These custom Shares are copied over as a result of adding the new DPs into the DP Groups to update content. There is no Package Deployment in SCCM to create these shares on the new DP. Nothing is deployed to any of the Collections that these DPs are a part of that create these shares. Plus, the new DPs do not have the SCCM Client installed yet as I am trying to force all logs. So the process of copying over these Custom Shares only happens as a result of adding the New MP/DP servers to the DP Groups for syncing content. NOTE: The New MP/DP Servers are set as Pull Distribution Points. I would expect as part of adding the New DPs to the DP Groups and being set as a Pull DP that they would update Content and Pull from the assigned DP. What I am trying to figure out is how, with no deployment, are the Custom Shares being copied to the root of the DP Drive on the New Server. This is not a huge problem except I would like to update this process to include new tools to sync across DPs. Any help is appreciated to point me in the right direction. Just trying to understand what is managing this copy process of Custom Shares to a new DP. NOTE: This is only for Custom Shares at the root of the DP Drive. It does no sync the non-shared folders at the root of the DP drive. Thanks Rob
  2. Some clients being deployed Windows 10 Feature Update in SCCM Windows 10 Servicing Plan are failing to install Windows Updates following the update from 1511 to 1607. I would like to troubleshoot this using client logs as there is no information on the server side. Are there any specific logging that occurs on the Client system during the update from one current branch version to the next? Should i be looking just at normal Get-WindowsUpdate log output? Or is there something that shows the entire process of updating from one Windows 10 version to the next? Any assistance would be appreciated. Thanks Rob
  3. Looking to upgrade current SCCM environment from 1610 and skip over 1702 going directly to 1706. Current Configuration Below SCCM Current Branch 1610 ADK 1607 MDT 8443 Actively Deploying Windows 10 1607 and light Testing with Windows 10 1703 deployments. Looking at current support docs it looks like ADK 1607 is not compatible with SCCM Current Branch 1706. https://docs.microsoft.com/en-us/sccm/core/plan-design/configs/support-for-windows-10 However, it is recommended that if you are actively deploying Windows 10 1607 via OSD that you stay on ADK 1607. Trying to determine what are the best steps to upgrading without breaking the OSD/Task Sequences environment. 1. Should I only upgrade the environment to SCCM 1702 Current Branch and stay on ADK 1607 till our Client team(handles OSD) is comfortable moving to Windows 1703 Deployments? The article above says SCCM CB 1702 is backwards compatible for ADK 1607. 2. Or is it recommended, even though we are still actively deploying Windows 10 1607 for Prod, to upgrade the ADK to 1703 and then move to SCCM CB 1706? Trying to better understand, if the recommendation is to stay on ADK 1607 if you are actively deploying Windows 10 1607 in your environment, what are potential risks in upgrading to ADK 1703. 3. Final concern to list here is the what are the risks in upgrading to the either SCCM CB 1702 or 1706 as it relates to MDT 8443. What has the potential in breaking? Any info would greatly be appreciated. Just want to move forward with a better educated decision. I have been reading articles and going through forums to confirm potential risks but looking for a little advice based in the current environment setup.
×
×
  • 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.