Tuesday, 9 June 2015
However sometimes you may wish to force a client to become an RVP or even prohibit it from becoming an RVP, in order to do this locate the following registry key:
The key is contentsystem.client_type, this can be set to one of the following values:
0 = Standard Client
1 = Preferred Client
-1 = Prohibited Client
Set this and restart the AdaptivaClient Service and the client should behave as you have set. You can verify successful RVP election via the Adaptiva Workbench, Network Topology perspective.
Having very large policies causes extra processing on the client side and can seriously impact performance, I have seen environments in which all content was being autopushed to all machines, this seriously impacted the product and the strain it caused on the clients and content refresh cycles were incredibly vigorous causing big delays and slowdown.
Whilst I am on this topic it is also worth noting that setting content Auto push policies to 2 hours is more than adequate and again best practice, ASAP is not (as you might think) the better option here.
I had performed a side-by-side migration of SCCM 2012 to a new site, along with an Adaptiva OneSite migration, at times I had subnets with clients from both environments and as such as made extensive use of this GUID, particularly when imaging new machines.
The problem is that when you boot a device to Windows PE for imaging the full Adaptiva OneSite Client is not used as an ACP (Alternate Content Provider) to download content, rather the executable OneSiteDownloader.exe is used instead.
OneSiteDownloader.exe has no knowledge of any Server GUIDS, and when a migration has occurred this can cause issues. Since a migration has taken place PackageIDs will match in both the new and the old environments but the hash will not (see where im going with this?)
The Client in Windows PE will happily download the content with ID of ABC0012 via the ACP and pass back control to the SCCM Client at which point a hash check will occur and cause a failure, (unless of course you have made no modifications to the package between migrations, but lets assume you have)
The fix for this and to ensure that OneSiteDownloader.exe talks only to clients with the correct server GUID is rather simple, at the beginning of your task sequence (or on a collection of your choice) create a task sequence variable named:
Assign this variable the Server GUID from a client, which can be found in the following registry location:
Voila! your clients will stop generating hash errors and image correctly :)
There are a few circumstances under which content will be removed from a client, these are listed below:
- If you have auto-publishing enabled (and you should!) if the content is unpublished within the Adaptiva Workbench it will be removed from client devices
- If the Content is deleted from Configuration Manager it will be removed from client devices
- If the content has become corrupted will be removed from client devices (we cant really avoid this one)
- If the hard drive space on the local machine is nearing empty and space is required by the user or Operating System/OS. In this case the content that is most prominent on the subnet will be removed from the machines cache.
Set the following value to True:
The next time the service starts the client will communicate with the server, activate, and will be assigned a new unique ID.
Adaptiva OneSite as a product is excellent, however the documentation at this stage is somewhat lacking, therefore I am taking the time to blog my discoveries over the past year with regards to the product for the benefit of myself and others.
This will be in no particular order, rather just a collection of thoughts / findings around real world usage of the product, enjoy :)