Q&A SCCM is great…but is it holding you back?

Hope you found our webinar last week informative. If you missed the live event or watch to watch highlight clips, it is now available on-demand. As always, great to see questions coming in throughout the session, but we didn’t have time to answer all of them, so here’s a wrap up.
What about the new Peer Cache feature in CM?
In the April Technical Preview, Microsoft introduced an extension of the Windows PE Peer Cache feature that enables all content types – so applications and software updates as well as packages. And it is available in the full CM client as well as in Windows PE during a Task Sequence. I did publish a blog back in May on that first release and it didn’t work too well – there were a few issues with it. I understand that these issues have been ironed out in subsequent Technical Previews but the feature didn’t make it into the 1606 Current Branch release (maybe it will appear in the 1610 release due in the next few weeks).
Another improvement that Peer Cache offers over Windows PE Peer Cache is that it uses site Boundary Groups to define ‘local’ subnets, so it can use content from peers in other subnets within the same Boundary Group. Although you may have seen that the 1609 Tech Preview has changed the way that Boundary Groups work. So I’m inclined to wait until the feature goes into the production Current Branch build.
One of the biggest concerns I have with this option is that – as with the Windows PE Peer Cache today – clients will only get content from a local peer if the peer has finished downloading the entire content. If you think of a scenario where you deploy something out (say a Windows 10 quality update, 1GB) to 100 devices at the same time in a remote site. Naturally, some clients will start downloading the content before others based on where they are in their policy refresh cycle, but inevitably from the start, multiple clients are going to go straight to the DP as no local peers have all the content yet. With a large update, if the WAN link is particularly slow, you could end up with every client going over the WAN as none of them have enough time to fully complete the download so they can serve it to another peer. And of course all this is being downloaded by BITS – BITS is going to saturate your network if you have all those clients downloading at the same time.
In my opinion, if you want to use a Microsoft solution you’re better off with BranchCache, as it will generally behave a lot better when multiple clients require content at the same time. And with BranchCache, clients can use partial content on peers – it doesn’t have to wait for the entire content to be cached on one or more clients.
How does Nomad’s Reverse QoS analyse how much bandwidth is currently being used?
Basically the way that Reverse QoS works is that as we’re downloading the content, we measure the end-to-end turnaround time of each block of data, so it’s not only taking into account the bandwidth but also latency and performance on the remote host (DP or peer). So if one block takes longer than the ones before it, we know there is congestion appearing on the network and we immediately back off accordingly by reducing the rate at which we transfer blocks. So we’re constantly using the data transfer to monitor the bandwidth usage on the network and adjusting accordingly.
We’re not planning for Windows 10 until late next year. What’s the value from 1E Nomad in my environment today?
Even if Windows 10 is a year or more away, if you’re using ConfigMgr for any software deployment or software updates, you can get an immediate benefit from Nomad. It provides an opportunity to start reducing your DP infrastructure right away, or improve network performance, patch compliance and user experience in any remote locations where you don’t have any DPs.
If you’re still deploying Windows 7 to new devices, you’ll get all the same benefits with OS deployment using Nomad that we’ve highlighted in this webinar, using PXE to deploy bare-metal devices, peer-to-peer transfer of the image, drivers and applications and storage of user data on local peers if needed. And now that Windows 7, 8 and 8.1 updates are cumulative, you’ve now got big chunks of update content to distribute to all your clients every month.
One opportunity that many people overlook is that you can actually deploy Windows 7 64-bit with UEFI (I’ve heard some people are receiving devices from their vendor with Windows 8.1 or Windows 10 installed and running UEFI with Secure Boot, and they’re wiping that, resetting the firmware back to legacy BIOS emulation and loading up a Windows 7 image.
If you have 64-bit hardware and a 64-bit image – start deploying that to your new devices with UEFI enabled (you’ll need the Compatibility Support Modules enabled and you won’t be able to use Secure Boot), but when you come to migrate these to Windows 10 later, you can take advantage of an in-place upgrade (no need to wipe and load) and simply enable Secure Boot, which you can do with the Nomad BIOS to UEFI feature.
What performance impact is seen on the Nomad master?
First, it’s important to note that the Nomad master is dynamically elected whenever content is required within a subnet, so it’s rarely the same machine every time. Once elected, the peers connect to a file share on the master, so the performance hit is basically memory and processor resources handling an SMB connection to the peer – pretty minimal. We limit the number of simultaneous connections to six to keep that impact low, but that doesn’t mean we can only distribute content in batches of six workstations – we’re intelligent about it. In most cases the peer is pulling content from the master quicker than the master gets it over the WAN from the DP, so when a peer ‘catches up’ with what the master has in its cache, the peer will disconnect to allow another peer to take the available connection. With our Fan-out feature, you’re not restricted to a single master serving content, so the load is spread across multiple peers, each serving 6 simultaneous connections. As our Reverse QoS feature responds dynamically to the time it takes to get each block of data (whether across the WAN or on the local network), if the elected master starts to get busy the peers will back off the rate they request packets from it. We have hundreds of customers that have been using Nomad for many years with no noticeable effect on the user experience while Nomad is doing its thing.
How do you tell which SCCM version you’re on?
You’d think it’s as simple as going to Help – About in the console. But that’s just going to give you a full version number. Check out https://www.systemcenterdudes.com/sccm-2012-version-numbers/ – it’s a great resource that you can use to identify exactly what you’re running from the full version number.
Why should Nomad be used over BranchCache?
The slide below from the webinar identifies the key benefits that Nomad gives over BranchCache. The most important distinction is that Nomad reliably manages network bandwidth whereas BranchCache relies on BITS, which is incapable of doing so.
Also check out this more detailed blog https://www.1e.com/news-insights/blogs/peer-to-peer-content-distribution-options/ that highlights the benefits of Nomad.

What are the network requirements for Windows PE Peer Cache and Nomad (broadcasting enabled etc.)?
Both Windows PE Peer Cache and Nomad use a broadcast to locate peers on the same subnet. If broadcasts are disabled (as is becoming more common in wireless environments), both will result in clients going back to the DP (although we’re releasing an update soon that will sort this out for the wireless scenario), but Nomad’s reverse QoS will always prevent network congestion if multiple clients are downloading over the same WAN link.
Client firewalls are another consideration. By default, Windows PE Peer Cache uses port 8004 for its broadcast communication with peers and Nomad uses port 1779. Both are configurable – the Nomad installer will create an exception in the Windows firewall but if you’re using other client firewalls you’ll need to create an exception manually. Windows PE Peer Cache uses HTTP/HTTPS on port 8003 (customizable) to get content from a peer (the CM client runs an HTTP server), whereas Nomad uses standard SMB ports (445).