I want to Thank You all for this journey, your suggestions and comments on this blog for all this time!

This is my last post here BUT the journey continues on this new blog of mine: https://georgebethanis.wordpress.com/

I hope you enjoy too ;)

George

The answer is this: Yes, you can use the SCCMContentLib from the secondary site for the new deployment point, without a new transfer of the content.
You will have to Back up this folder, before uninstalling the secondary site – just to make sure you won’t lose it...

Can you confirm if any of these users were ever removed from the Intune User collection, under Configuration Manager console, after enrollment?

If so, that would block the devices as the user would no longer be licensed, breaking the link between device and user, thus blocking the device..

If you check the ULS logs, you may find lines like the following:

w3wp.exe (0x05B8)        0x18C4        SharePoint Foundation        General        xxpm        High        Unable to execute query: Error 0x80131530        7114c45b-5454-4044-a996-f297eacef288
w3wp.exe (0x05B8)        0x18C4        SharePoint Foundation        General        8e2s        Medium        Unknown SPRequest error occurred. More information: 0x80131530        7114c45b-5454-4044-a996-f297eacef288

In that case, at first ensure that you have installed at least Service Pack 2 for SPS2010. This should be enough.

If not, then it seems that the cause of this issue, is the fact that you have a quite big list and you are probably surpassing the list threshold limit.
There might be a big amount of data/items per list and also unique permissions. So, the SQL query appears to be quite performance intensive.
In SP 2010, when your query result is more than 10,000 items, as an environmental control, SP denies your request. For farm administrators this value is higher; 20,000 items. (Reference: https://technet.microsoft.com/en-us/library/cc262813.aspx)

You will need to check and if needed edit your settings in this list, like the List View Threshold, List View Lookup threshold, enable a daily time window for large queries, etc…
Some examples on the values to be used: 20000, 12, 13 hours.
These settings are located in Central Administration Application Management > Manage Web Applications > click the specific Web application > General settings > Resource Throttling.

"Client: If the maximum size of the Configuration Manager client cache is exceeded by a software update package, the cache continues to increase beyond its specified limit."

By default, content will always remain in the cache until the content has been used/run. After that, it is available to be removed from the cache, but it not automatically removed unless the cache space is needed.
Of course, the admin can always force a cache deletion from the Configuration Manager Properties.

You may also check the below information from my colleagues:

One of the main concern about client cache is auto-empty mechanism. There are several scripts around the web that deletes client cache but be aware that client will not be notified so will try to use cached content if installation is not succeed yet.
If you configure the package properties with the option to persist content in the client cache, client does not automatically delete package content from cache. https://blogs.technet.com/b/meamcs/archive/2012/10/04/managing_2d00_configuration_2d00_manager_2d00_2012_2d00_client_2d00_cache.aspx

So,why the clients downloaded the full package?

Answer:
This is the current default behaviour of the download from UNC update method...
It only grabs the full definitions, even if deltas are available from the share...
This operation collects the full definitions, even if deltas are available from the share and this is a known issue for the Product Group.
Currently, we don’t have any specific  information if / when there will be a fix for this issue, but it will probably be addressed in some EP client update…

All required information is listed in the above two MS pages:

Networks disconnected from the Internet

It is unnecessary for your entire network to be connected to the Internet in order for you to use WSUS. If you have a network segment that is not connected to the Internet, consider deploying WSUS as shown in the "Distributing Updates on an Isolated Segment" illustration below. In this example, you create a WSUS server that is connected to the Internet but isolated from the intranet. After you download updates to this server, you can export the updates to media, hand-carry the media to disconnected WSUS servers, and import the updates.

Exporting and importing is also appropriate for organizations that have high-cost or low-bandwidth links to the Internet. Even with all the bandwidth-saving options described later in this guide, downloading enough updates for all Microsoft products throughout an organization can be bandwidth-intensive. Importing and exporting updates enables organizations to download updates once and distribute by using inexpensive media. See Set Up a Disconnected Network (Import and Export the Updates) for more information about how to export and import updates.

From <https://technet.microsoft.com/en-us/library/cc720448(v=ws.10).aspx>

Configure a Disconnected Network to Receive Updates

You can use Windows Server Update Services (WSUS) to manage updates to computers that are located on a network segment that is not connected to the Internet by following these steps:

1. Install a WSUS server on the disconnected network segment. This server is known as the WSUS import server.
2. Synchronize updates and metadata to a WSUS server that is connected to the Internet. This server is known as the WSUS export server.
3. Transfer the required updates and metadata from the WSUS export server to removable media.
4. Transport the removable media to the WSUS import server.
5. Import the updates and metadata to the WSUS import server.
6. Manage and download updates to client computers on the disconnected network segment by using the WSUS import server.

This topic assumes that you already have installed the WSUS servers.

In this topic:

• Match express file installation and language settings on export and import servers
• Export updates and metadata
• Import updates and metadata
•  

From <https://technet.microsoft.com/en-us/library/dd939873%28v=ws.10%29.aspx>

As you see above, It requires a WSUS server that does have Internet connectivity (all you have to do is install an Internet facing one – or use an already existed WSUS - standalone WSUS server to do the export from)
and then you use the WSUSUtil command to export and then import to the isolated SUP.
More information you may also find here:

How to Synchronize Updates Using Export and Import   https://technet.microsoft.com/en-us/library/bb680473.aspx

How to move WSUS from one server to another   https://blogs.technet.com/b/sus/archive/2009/07/02/how-to-move-wsus-from-one-server-to-another.aspx

 My colleague wrote also this very detailed blog post, which takes you through the steps and automations:

ConfigMgr Software Updates on an Isolated Network (still valid for ConfMgr12)

https://blogs.technet.com/b/aaronczechowski/archive/2008/11/11/configmgr-software-updates-on-an-isolated-network.aspx

You may also check the below post, which describes an update for the WSUS server; this update removes the 2 GB limitation on the export file size, which can be exceeded if you synchronize updates for a lot of products.

Problem Solved: The WSUS Export Bug https://blogs.technet.com/b/wsus/archive/2013/04/09/problem-solved-the-wsus-export-bug.aspx

Since the Configuration Manager server is completely isolated from the internal network,  it cannot communicate with the upper ConfMgr hierarchy, so cannot be used..

First of all, ensure that there is enough free disk space on the server.

Then, I have attached below the first method, based on this Technet blog post: https://blogs.technet.com/b/heyscriptingguy/archive/2013/04/15/installing-wsus-on-windows-server-2012.aspx
(try to follow it step-by-step)

Let’s start with the easiest, which is the WID database. I say easiest because it really comes down to just running a single line of code to get everything installed. Just to see what might be installed, I can use the WhatIf switch first.

Install-WindowsFeature -Name UpdateServices -IncludeManagementTools –WhatIf

From the looks of it, not only will WSUS be installed, but we also will be installing the WID database and some IIS components that are used for client check-ins and other things. I am confident that this is what I need, so let’s remove WhatIf and let it run again.

Wait for a bit…

 And we are now finished with the installation. As you can see, we have a message stating some additional configuration may be required before our WSUS server can be up and running. In this case, we still need to configure a location for the update files to be stored.

This is where wsusutil.exe will come into play. This executable is located at C:\Program Files\Update Services\Tools. Besides the usual parameters that you can use with this utility, there is another set of parameters that become available when you use the PostInstall argument.

.\wsusutil.exe postinstall /?

Note: If there is no WSUSUtil.exe in the Program Files\Update Services\Tools folder (in the Update Services folder) then the post install task will fail. Please check if exists. If not:
Please find WSUSUtil by searching for it on your Windows 2012 server > copy WSUSUtil into your  newly created Tools folder in the Update Services folder.

We have parameters for specifying where to store the content and for where to build the database, if needed. Note that this can be used to specify a database that is local or remote (you will see this used on a remote system later).

Before I say where I want the content, I had better create a folder to store it. I don’t want all of this on my system drive, so I will create the folder on my D: drive.

New-Item -Path D: -Name WSUS -ItemType Directory

Now I can run the following command to configure my content directory to download and save all of the update files to D:\WSUS.

.\wsusutil.exe postinstall CONTENT_DIR=D:\WSUS

And with that, we have now configured the content directory on another drive to save the update files.

A second method, could be the following:

 ** Uninstall the WSUS role.

** Uninstall the WID role.

** Remove the SUSDB.

** Delete hklm\software\microsoft\update services registry key and WSUS directory from the drive.

** Clear out the WSUS mmc cache by deleting the WSUS folder under %appdata%\microsoft\mmc

** Restart the computer

** Reinstall WSUS from the server manager or, Re-install WSUS role using power shell command "Install-WindowsFeature -Name UpdateServices -IncludeManagementTools"

** Perform the post installation again using the Powershell command.

A 3d method, would be the following – attached below:
(based on this TechNet post: https://social.technet.microsoft.com/Forums/en-US/e1003863-e331-46da-8803-e8625bb6324b/server-2012-wsus-postdeployment-configuration-fails-comprehending-the-log-file?forum=winserverwsus )

Upon closer inspection the specifics of my error were right there for me, I just had to look at it long enough to decipher the details.  What I now read is that Post-deployment configuration finds a file called UpdateServices-Services.xml (I found it in Windows\System32\ServerManager\ComponentConfiguration\).  It determines that ContentLocal=True which correctly indicates that my updates are to be stored locally.  It proceeds to inquire about the ContentDirectory, but comes back without a value.  Here are my UpdateServices-Services.xml file contents

<?xml version="1.0" encoding="utf-16"?><INSTANCE CLASSNAME="ServerComponent_UpdateServices_Services"><PROPERTY NAME="ContentDirectory" TYPE="string"></PROPERTY><PROPERTY NAME="ContentLocal" TYPE="boolean"><VALUE>true</VALUE></PROPERTY></INSTANCE>

I can see that the ContentLocal property did indeed have the value true, but the ContentDirectory property did not have a value.  I now needed to figure out if a String value could be specified in the same way a Boolean value was, or if it needed quotes around it, or was supposed to be specified more like an attribute (learned about that somewhere along the way).  I couldn't find any conclusive websites, and I didn't want to just try it for fear of the Post-deployment configuration running with an invalid ContentDirectory.  Once again I returned to my log file and searched for answers at the https://go.microsoft.com/fwlink/?LinkId=235499 that was indicated.  I didn't find any exact matches, but eventually I found a sample .xml file that specified a string value.  It specified it as <VALUE>string</VALUE> with no brackets, so I knew to specify mine as <VALUE>C:\LocalMSUpdateCache</VALUE> and saved it.  My UpdateServices-Services.xml now looks like this:

<?xml version="1.0" encoding="utf-16"?><INSTANCE CLASSNAME="ServerComponent_UpdateServices_Services"><PROPERTY NAME="ContentDirectory" TYPE="string"><VALUE>C:\LocalMSUpdateCache</VALUE></PROPERTY><PROPERTY NAME="ContentLocal" TYPE="boolean"><VALUE>true</VALUE></PROPERTY></INSTANCE>

I returned to Server Manager -> WSUS and re-attempted the Postdeployment configuration.

If all the above fail, please run the Process Monitor tool https://technet.microsoft.com/en-us/sysinternals/bb896645.aspx   – during the repro of the issue – and check the generated Process Monitor trace (so you know exactly where it is failing).

If all fail, this is the information for the OS in-place upgrade (this will also upgrade WSUS):

 Upgrade of the Site Server Operating System

Configuration Manager supports an in-place upgrade of the operating system of the site server in the following situations:

• In-place upgrade to a higher Windows Server service pack as long as the resulting service pack level remains supported by Configuration Manager.
• In-place upgrade from Windows Server 2012 to Windows Server 2012 R2.

https://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_UpgradeInfrastructure

 You will just have - before the upgrade - to stop and disable all of the ConfigMgr related services…

Then – after the OS upgrade – you may check if everything is ok and then, upgrade to the latest CM12 R2 CU.

Useful log files are located in the %temp% directory of the user who ran the installation process..

It depends on each customer to create a working backup plan and test it in a regular interval.

More information you may find at the following links:

https://technet.microsoft.com/en-us/library/ee662536(v=office.15).aspx

https://technet.microsoft.com/en-us/library/gg266384(v=office.15).aspx

https://technet.microsoft.com/en-us/library/ee428315(v=office.15).aspx

https://blogs.technet.com/b/meamcs/archive/2013/02/23/sharepoint-2013-backup-with-powershell-and-task-scheduler-for-beginners.aspx

Plan for backup and recovery in SharePoint 2013 https://technet.microsoft.com/en-us/library/cc261687(v=office.15).aspx

I would also suggest you to backup the following (regarding customizations, settings, folders, etc) – as a general plan:

The various components included in a SharePoint system:

-              Content

-              Customizations

-              Configurations (Office SharePoint server)

-              Binary Files

-              Configurations (IIS)

-              Binary Files (OS)

For backing up and restoring both operating system and sharePoint program files, we recommend that you use Windows server Backup (NTBackup) on a regular basis. Additionally, we recommend that you keep copies of the installation disks for your operating system, SharePoint and software updates both onsite and offshore. This will help you roll back software updates and validate that you have correctly reconfigured your system.

To Backup your IIS configurations:

IIS configurations are set in Central Administration or IIS Manager on each WFE. In addition, these configurations are also set on any computers in your system that runs SQL server  Reporting Services (SSRS).
IIS configurations are stored in the IIS metabase and include the following:

-              Application pool settings, including service accounts

-              IIS compression settings

-              Time out settings

-              Custom ISAPI filers

-              Computer domain membership

-              Network Load Balancing settings

-              Host Header entries

-              SSL Certificates

-              Dedicated IP Address settings

We recommend that for each WFE server, you should document ALL configurations.

In SharePoint, the IIS configurations are set in CA and stored in the Configuration Database. Although you can backup both configuration database and CA, they contain computer-specific information and can only be restored to an environment that is configured to be precisely the same, including software updates, server names and number of servers. In order to back up the configuration database you must take the farm completely offline or use DataProtectionManager (if installed on your environment).

We recommend that you document all settings in CA and by all settings, we mean :

-              Application pool settings, including service accounts

-              DB names and locations

-              Web Application names and databases (ensure that you have documented the content database names associated with each Web App).

-              Crawler impact rules

-              Farm-level search settings

-              External service connection settings

-              Workflow management settings

-              Activated features

-              Alternate Access Mappings settings

Customizations for SharePoint sites may include:

-              Master pages, page layouts and CSS (stored in the content database for a Web Application)

-              Web parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows or workflow activities and conditions

-              Third-party solutions and their associated binary files and registry keys, such as IFilters

-              Changes to standard XML files

-              Custom site definitions (webtemp.xml)

On WFEs, customization files are stored in Program Files\Common Files\Microsoft Shared\Web Server Extensions\12.  Some customizations also write changes to the Web.config file.

We recommend that you backup these directories with Windows Server Backup:

-              Program Files\Common Files\Microsoft Shared\Web Server Extensions\15

-              Inetpub (the IIS Virtual directories)

-              C:\Winnt\assembly (Global Assembly Cache for .NET Framework code assemblies)

You could also, package all customizations as solutions (as the container) in order to deploy.

To get to a clean state, please delete the DpmFilter* files from “System Volume Information” using the following steps:

1.       On an elevated command prompt:
2.       fltmc unload DpmFilter (on all cluster nodes)
From one of the Cluster nodes
3.       psexec -s cmd          
(psexec is sysinternal tool, used to run cmd under system account)
4.       In this command prompt (running as system):
5.       cd C:\ClusterStorage
6.       for /d %i in (volume*) do del /s
"%i\System Volume Information\DpmFilter*" 
(* includes DPMFilterBitmap{Guid}, DPMFilterStatus, DPMFilterLog, DPMFilterTrace*)
7.       verify files are deleted by “dir /s /b DpmFilter*”
8.      exit
Then load the filter again on all nodes
9.       fltmc load DpmFilter (on all cluster nodes)
Run DPM Consistency check to re-start normal protection.

You will also need to make sure, that you have the latest updates for Windows Server 2012 Hyper-V cluster. Please see:

2878635 - Update is available that improves the resiliency of the cloud service provider in Windows Server 2012: December 2013
https://support.microsoft.com/kb/2878635