BzowK Posted March 18, 2016 Report post Posted March 18, 2016 Hey Guys / Niall - I recently started at a company which started the installation of Configuration Manager 1511 about a month prior to my arrival. I was brought in in part due to my prior experience with SCCM and to assist getting many parts of it up and running. The Story Recently, during initial client deployment; they found out that .NET 4.5.2 was the minimal .NET Framework version for the 1511 client. Unfortunately, there are many key applications used by the ~10,000 staff which are incompatible with .NET. I put a "fix" together which seemed to work for most that basically enabled .NET's legacy mode, but to test it the proper way would take a long time and important deployments plus other tasks are lining up daily. After much discussion, it was decided to test deployment of the latest "legacy" SCCM client to the environment instead of the 1511 version - at least for a month or two. The reason is mostly due to it's pre-requisite not being .NET 4.5.x mostly. Even though 1511's latest features may not work, I got word from Microsoft that everything else would work fine. Yes, I understand that this may not be the first choice of many and wasn't for me, either; until I thought of the times in the past when a primary was upgraded and some clients which never were still worked as desired. What Has Been Tried I didn't plan on replacing the actual client installation files on the Primary, but deploying using a different method therefore grabbed the files from a 2012 R2 ISO, placed them in a share, create ClientPatch folders, added the latest MSPs, and started testing. I then attempted installation on a couple of VMs which had an OEM installation of Windows 7 x64 Pro (what we use), pointing to the source I created, and using a few strings similar to the below: "ccmsetup.exe" /source:"\\server\2012R2Client\CLIENT" /mp:PrimaryNetBIOS SMSSITECODE=ABC SMSCONFIGSOURCE=P Note: The path listed as the source above was to the root folder with ccmsetup.exe, the i386 folder, and x64 folder in it... The Issue No matter what string I tried, ccmsetup.log kept showing that the installation would download and use the Client source from the Primary. Once I looked more closely at the log, I saw why (I think.) Seemingly, the client is checking the manifest stored in AD as is seeing that the client I'm trying to install doesn't meet the minimum version requirement therfore is downloading it despite my string configurations. Below are a few lines showing what I'm talking about... CcmSetup version: 5.0.7958.1000 Checking if manifest version '5.00.8325.1000' is newer than the ccmsetup version '5.0.7958.1000' Downloaded manifest from the source and its newer than the running ccmsetup. Will download ccmsetup from source as well. Here's the full log file if interested... ccmsetup.log So - assuming this is correct, is there a workaround that I may use to get around this? Any suggestions are appreciated - Thanks! Quote Share this post Link to post Share on other sites More sharing options...
YPCC Posted March 26, 2016 Report post Posted March 26, 2016 interesting one. Wasnt aware 1511 required 4.5.2. May need to review my migration plan. In your case, from what i understand this is the series of events taking place when the client installs. - run ccmsetup from your location will sitecode etc paramters - Its then querying AD for a Management Point (Performing AD query: '(&(ObjectCategory=mSSMSManagementPoint)(mSSMSDefaultMP=TRUE)(mSSMSSiteCode=ABC))') - Off the back of this query, it is automatically finding a suitable distribution point (Found local location 'http://SCPRIMARY.corporate.abc.com/SMS_DP_SMSPKG$/ABC00003') - then downloading the ccmsetup.cab (GET 'http://SCPRIMARY.corporate.abc.com/SMS_DP_SMSPKG$/ABC00003/ccmsetup.cab') - which contains the manifest (Successfully extracted manifest file C:\Windows\ccmsetup\ccmsetup.xml from file C:\Windows\ccmsetup\ccmsetup.cab.) Try this: - Make sure all the files required to install the client are on the machine then take the machine off the network and install the client. This way it cannot connect to AD, therefore wont find the management point and distribution point. If that method works you will need to consider how to arrange offline installs. - I've never really looked into how distribution points store content, but if its stored in its original format, maybe you can consider editing the CAB file on the DP by importing the manifest XML file into it. Then even if it downloads the cab, it will contain the manifest you want. Just a thought. Quote Share this post Link to post Share on other sites More sharing options...