I work for a large oilfield services organization. Prior to implementing Nomad, there were times we would receive phone calls from the Network Team about bandwidth consumption, or an office somewhere that saw our port taking up their pipe and knocking off phones or some other system.
Before Nomad: 400+ DPS serviced by about 30 Secondary’s
After Nomad: 0 DPs + 7 Secondary sites
How is it possible to improve performance by removing all the local files?
- Spending less time fixing broken DPs or re-pushing packages to DPs
- Less server infrastructure equals fewer licenses and hardware cost!
- Nomad is self-managing
How does Nomad work when a package is requested?
When the software is requested, the machine will look on the local subnet for the files. If not found, it runs the search order:
- Local Subnet
- Active Efficiency – adjacent subnet search
- ConfigMgr Infrastructure
Within this search order it will also prioritize:
This intelligent design helps prioritize data. It is also looking at updates and other election attributes.
With “Fan out”, machines can share files once they have a given percentage.
This allows us to push out a single package, WIM, or even patch the entire company without impact to any part of our network. The Reverse QOS is so intelligent that machines can image on a slow VSAT link, first pulling from a local machine and if necessary, slowly pulling over the WAN.
Understand that as we move to a “cloud” model where we don’t local data, that sometimes it will take time to pull. Imaging could take 3 hours or 20 hours, but the goal is to complete the process, not the speed at which it happens. If this is the only machine over a VSAT and there are no files and then you still image, it might take 24 hours but the link will be usable. Yes, we have done this before!!!
Most of this information you can find on the 1E site but I think its always better to hear it validated by a user!
Manually Caching files
This link allows you to export a Task Sequence into the following type of commands:
“C:\Program Files\1E\NomadBranch\SMSNomad.exe” –s –pp=”https://Server.Foo.com:132/SMS_DP_SMSPKG$/AB100002″ –prestage –ver=16
This is a native command to cache a package/application from a DP. You can write this for any application.
It is important to note that Applications don’t have versions, what changes in the app is the ContentId.
But why do we care, doesn’t Nomad have a precache method? Yes, but here is where you might want to use this!
Scenario: Merger Company
You’re merging with another company and you need to get your files to that infrastructure to be able to image as soon as the network is merged. This link allows you to create a batch or command file of the packages. This can be run on that box, assuming Nomad is installed, servers are accessible, and the data will be there when the rest of the clients move. What this means is that the other company SCCM client can be on the box or not but the files are SCCM independent. Now when the new SCCM client is installed and wants files it can pull them from this other box, no need to wait for them to cache. Thus, speeding up migrations of machines into the new company.
Scenario: Remote fixing of a machine
A machine is drifting due to a compliance check. You could use the Compliance to move the machine to a collection which has a policy to run the program on the machine then you update the collection and move the machine out. But why bother, with the ability to precache you can simply pull the program down, wait for it to complete by checking the registry and launch your command all within your Compliance Check! What is nice about this is that you don’t need to distribute to every DP, no boundary is necessary, you can pull from a single DP or you can determine which one to pull from, saving space on the DPs!
How Pre-caching is effective in pushing files to a set of machines
With the advent of the Pre-caching Jobs you are now able to cache large applications or your Imaging Task Sequences to certain machines faster and easier than you had with the old method. The machine will check in every 24 hours for files.
What if you want to force it? Sure.
If you want to speed up the poll time of the machine to check for a cached package you can change this
Be aware you could create more stress on the box because it is checking more frequently. Ideally, you should cache the OS Task Sequence to each subnet or each shared subnet, say in a large building.
But what else is it useful for?
What about a major upgrade to all the machines like a line of business application that you will deploy to 60% or 100% of the machines?
It is also useful to precache the large packages from Auto desk to the machines. Then when the application is ready to deploy the files are already on the machines. No more need to use the required package with a distant deployment time to force it to cache.
1E has given you the tools, it is your job to tweak and extend those tools give you more power than what they were designed for originally!