I apologize. It wasn't Kent's post I was thinking of. It was this one:
http://blog.coretech.dk/mas/upgrade-sccm-1511-to-1602-when-service-connection-point-is-set-to-offline-on-demand/ Although Kent's post might be out of date too: http://blog.coretech.dk/kea/system-center-configuration-manager-1511-dynamic-updates/ Also, for everyone's benefit, ServiceConnectionTool.exe crashes if you run it directly from read-only/mounted-ISO locations. (I think it wants to write a log to its immediate folder and cannot.) So copy it elsewhere locally prior to trying to run it. /begin rant mode So why isn't there a GUI for this? Or why do I have to do it at all? /end rant On Fri, Nov 18, 2016 at 7:04 PM, Mike Dougherty <mike...@gmail.com> wrote: > I thought I would float this to list prior to mentioning it on Uservoice > or trying to open a ticket: > > In my environment, we upgraded our lab (which does not have internet > access) to 1606 from ConfigMgr 2012 R2 SP1 CU3 via the VLS 1606 media today. > > (FYI, we used this helpful blog post as a guide, so reading it might help > with the terminology I will use: https://www.niallbrady. > com/2016/01/08/how-can-i-use-updates-and-servicing-in- > offline-mode-in-system-center-configuration-manager-current-branch/) > > When we ran this command to "connect" our exported CAB data file > > ServiceConnectionTool.exe -connect -usagedatasrc c: > \temp\UsageData\usagedata.cab -updatepackdest C:\temp\UpdatePacks > > the resulting downloading/extracted content in the "updatepacks" folder > was 10.5 GB. > > (Actually, as a side note, it seems the behavior of ServiceConnectionTool. > exe has changed in 1606. In 1606, it looks like it require the FOLDER > path of the .cab file, not the explicit filename of the .cab file itself. > The correct 1606 syntax is: > > ServiceConnectionTool.exe -connect -usagedatasrc c:\temp\UsageData - > updatepackdest C:\temp\UpdatePacks > > If you specify the exact path to the .cab file, the command states that it > couldn't find a .cab file containing telemetry data or something along > those lines. > > Niall/Kent, if you're reading this, you may want to update your respective > posts about offline servicing to reflect this new syntax/behavior (after > testing for yourself, of course). > For the record, the example when running ServiceConnectionTool.exe -? is > correct as it refers to the folder and not the specific .cab file path.) > > > I'm not sure exactly what was downloaded directly vs. what was extracted > by ServiceConnectionTool.exe (as the updatepacks folder had a number of > subfolders with identical-looking content), but there seemed to be a lot of > duplication: > > For example, in the folders created in the "updatepacks" directory, six > folders were created (either downloaded or extracted from .cab files) > Three of the folders had the exact same number of files with the exact > same size: 1726 files; 498 folders; 807,896,930 bytes. > Two of the folders the exact same number of files with the exact same > size: 1743 files; 498 folders; 813,694,292 bytes. > The sixth folder was unique in number of files and sizes. > > [image: Inline image 3] > > > I haven't dug more closely and compared hashes of individual files to see > what is exactly duplicated inside the folders themselves. > > There were also at least 5 CAB files which seemed to be two unique files > at 600 MB apiece. > > [image: Inline image 1] > > (The 12MB cab files have ever-so-slightly different sizes.) > > After of all that and importing the resulting 10.5 GB worth of > "updatepacks" folder back into our lab environment, it detected exactly one > hotfix available for install after our upgrade: https://support. > microsoft.com/en-us/kb/3202796 . > I did some digging and found that update content for that specific hotfix > KB is about 29 MB. > > So yeah. > > 10.5GB of "updatepack" content vs. 29 MB of actual hotfix change content? > > Something seems weird to me. > > Lemme know if you have any questions or if I should go ahead and post this > to Uservoice or submit a bug report somewhere. > > Or if this is by design somehow. > > But, hey on the plus side, our new 1606 test site is working great. > > > > > > > > > > > > > > >
