System Management

ConfigMgr 2012 and utilizing BranchCache in your environment basics

Posted on Updated on


There are plenty of articles out there for BranchCache but I wanted to through one together that covers the over-view of the basics with use with ConfigMgr 2012 and the logs that you can use to verify it is working.

Let’s first start with a little background on BranchCache:

* Was introduced with Windows Server 2008 R2 and Windows 7

* BranchCache clients can act as peer distribution points for other BranchCache clients on the same subnet (key other BranchCache clients)

How it works:

1.A BranchCache Content Server (BCS) breaks content into blocks with unique hashes for each block.

2.A BranchCache client requests content from the BCS.  The BCS responds with a list of blocks and hashes.

3.The client queries local peers for any of the blocks.

4.If the blocks are found on the local subnet, they are retrieved from peers.

5.If the any block is not available from a peer, it is retrieved from the BCS.  Once retrieved, it is made available to peers.

Branch Cache has two modes of operation:

– Distributed cache mode: content cache at a branch office is distributed among client computers.

– Hosted cache mode: content cache at a branch office is hosted on one or more server computers called hosted cache servers.

Distributed cache mode is designed for small branch offices that do not contain a local server for use as a hosted cache server. Distributed cache mode allows your organization to benefit from BranchCache without the requirement of additional hardware in branch offices.

Is there a way to pre-stage distributed and hosted cache content:

Yes, in some cases. Pre-hashing and preloading content is a new BranchCache feature for Windows Server 2012 and Windows 8.

For distributed cache mode, your content servers must be running Windows Server 2012, and your client computers must be running Windows 8. For hosted cache mode, your content servers and your hosted cache server must be running Windows Server 2012

Preloading content on hosted cache servers: https://technet.microsoft.com/en-us/library/jj572970.aspx

Branch Cache Ports:

  • Http (port 80) for content retrieval using BranchCache retrieval protocol
  • WS-Discovery (port 3702 UDP) for content discovery in distributed cache mode
  • HTTPS (port 443) for content upload in hosted cache mode using hosted cache protocol

Next let’s look at how it fits into working with ConfigMgr 2012 R2:

* Distribution points also support a feature of Windows Server 2008 R2 \ Windows Server 2012 and Windows 7 \ Windows 8.1 for BranchCache

* When enabled a copy of content retrieved from a server is cached in the branch office

* BranchCache feature caches HTTP, HTTPS, BITS or SMB based content

* There is no special configuration option in ConfigMgr 2012 to enable BranchCache since it’s not a feature or Configuration Manager 2012

* The only thing you need to do to configure is that your deployments are enabled for downloading and running the applications locally

* ConfigMgr only supports Distributed cache mode for BranchCache


– Software Update Deployments: Download Settings Dialog (Assure to check Allow clients to share content with other clients on the same subnet)

– Package Deployments: Distribution Points Dialog (Assure to check Allow clients to share content with other clients on the same subnet)

– Application Deployments: Content Tab on the Deployment Type (Assure to check Allow clients to share content with other clients on the same subnet)

Now that we have touched on the background of BranchCache and how it fits into play with ConfigMgr 2012, let’s look at some items that are important to note when using BranchCache in your environment:

* In order to benefit from BranchCache all machines at the location meant to utilize Branch Cache must be configured at the Operating System level for BranchCache, machines not configured will not partake in the BranchCache sharing

* BranchCache is not managed nor an active component for ConfigMgr simply utilized by deployments for systems that are enabled to support BranchCache

Ways to verify Branch Cache from a ConfigMgr deployment:

A. The following logs come into play with BranchCache

– DataTransferService.log

– FileBits.log

– ContentTransferManager.log

B. Validation Method for a deployment

(1) Start Performance Monitor

(2) Add monitor elements

(3) Add BranchCache (specifically)

– BITS: Bytes from cache

– BITS: Bytes from server

– Discovery: Attempted discoveries

– Discovery: Successful discoveries

– Retrieval: Bytes from cache

– Retrieval: Bytes from server

– Retrieval: Bytes served (show how much this computer is providing to other peers)

(4) Monitor these counters

(5) Deploy something NEW from SCCM ensuring that “download from distribution point” is enabled in order to force BITS.  You could also manually transfer data via BITSAdmin.exe

(6) Run this locally to see some good basic configuration and utilization info: netsh branchcache show status all

from Charles Allen’s Blog


Architecture Matters: Why We Re-Architected Everything When Our Competitors Wouldn’t

Posted on Updated on

good read by Brad Anderson, Corporate Vice President at MS, Enterprise Client & Mobility! Original link is here

A couple of years ago we had to make a very difficult choice about how we were going to deliver Enterprise Mobility management to our customers.

At the time, we knew that the solution had to be delivered as a cloud service since that was the only way we could help the 100,000’s of customers and 100,000,000’s of mobile devices using the solution stay up-to-date amidst the constant change in the world of mobility.

To do this, we had two options:

  1. Take SCCM and host it in the cloud and call it a cloud service
  2. Build a true cloud service from scratch

Not a day goes by that I don’t grow more grateful that we decided on the latter.

Choosing option #2 came with costs, however.

Building our solution from scratch put us a little behind in the Enterprise Mobility Management market, but the agility it has enabled has made that worthwhile. For example, consider the volume of new value we have released through the monthly updates to Intune since November 2014. This agility will remain a key part of our differentiation, as well as a key part of your ongoing value, for years to come.

As I mentioned in a previous blog post, when we decided to move our EMM to the cloud, we did not simply port SCCM to Azure. Instead, we decided to invest in a cloud service architecture for our solution to Empower Enterprise Mobility. Aside from the obvious difference of single-versus multi-tenancy, and the need to embrace and interact with other Microsoft Services (AAD, O365, etc.), we knew a modern architecture was necessary to allow us to really benefit from the advantages the cloud offers. These benefits includes our continuous (micro-service) deployment, elastic scale, technology heterogeneity, etc.

This setup also provides a huge amount flexibility and autonomy to our engineering teams – which means they can innovate, update, and improve services constantly.

Intune’s mobility micro-services are fully hosted in Azure and, even if we were in a single datacenter, this would provide tremendous benefits. However, with the global reach of Azure, the benefits of availability, performance and jurisdictional governance and sovereignty are massive. (This is a topic I’ll cover at length in a future post.)

This use of Azure is a huge advantage. There is a mantra we use here that “we will follow Azure wherever it goes.” With 19 “regions,” Azure truly has a global footprint. Each of those regions has one or more datacenters with built-in redundancy within the datacenter, as well as redundancy to other regions.

Microsoft is continuing to build Azure capacity around the world to keep up with accelerating demand, deepen the global footprint, and accommodate specific needs, like regulatory requirements that require data to be kept within a country (China) or region (EU).

As Azure continues to stand up data centers around the world, Intune and all of EMS will take advantage of the capacity to deliver services in that region. Currently, our services run in North America, Europe, and APAC – with geo-redundancy within each of those regions.


There is an incredible amount of innovation happening inside these Azure datacenters. Everything inside of them is automated and driven through policy, and, with our “Cloud-first” engineering principle, we prove out new capabilities in areas such as software-defined networking, software-defined compute, and software-defined storage at-scale in these cloud datacenters and then deliver them for you to use in Windows Server and System Center. This is one of the reasons why our pace of innovation has accelerated so much for our on-premises products.

We are also innovating how we house the compute, storage, and networking in our datacenters. One example of this is our Chicago datacenter (pictured below).



I think the last thing anyone would guess when looking at the containers above is that this is a cloud data center.

Each of those containers house about 2,500 servers and we can pull the container in, hook it up to the power and the network, and have 2,500 additional servers up and running in minutes. When it is time to upgrade to new hardware, we simply remove the old container and replace it with the latest and greatest. The speed and agility this provides us is phenomenal.

With this as a background, here’s how some of the Azure platform components that we use in Intune (and in all our services) provide the scale, performance, availability, and reliability required by our customers around the globe:

Within Intune, each micro-service owns its own data. This architectural setup is very different from a traditional on-premises client-server product where everything is usually written and read from a single database. The compute requirements of the Intune service is affinitized with its data allowing for performance and each micro-service can scale independently via independent service partitioning. This means that each micro service is able to make changes and updates without requiring communication and coordination with other teams. Everyone working on Intune is thus able to move faster and the changes in one micro service do not introduce risks in other micro services. Bottom line: You get more value and capabilities faster – and they are more resilient.

Resiliency is a native part of this architecture, and many of our micros-services rely on Azure Service Fabric for availability and scalability. To give you an idea of just how much we value the resilient nature of our infrastructure (and, by extension, your organization) consider this: We maintain 5 (yes, five) replicas of our data in many of our micro-services. As nodes in Azure go up and down, the Windows Fabric automatically brings up a new instance of a service partition replica. Thus, there is no single point of failure in the infrastructure nor the data. In addition to automatically spinning up new nodes and seamless service functioning when this happens, we can also add new nodes into our subscription. When nodes are added, we can start moving hot service partition replicas to the new nodes. This gives us tremendous flexibility.

Also important is the “geo-affordances” provided by Azure. As noted above, we keep a lot of data in memory affinitized to compute, but, additionally, we write out to Azure Storage for those micro-services that need data durability. Today, we use Azure table and blob. This data gets replicated using Geo Redundant Storage. With this type of storage, a transaction is replicated synchronously to 3 nodes within the primary region and queued for asynchronous replication to a secondary region (hundreds of miles away from the primary), where the data is again made durable with triple replication. As a result, if there is a disaster, we can pick up with the persisted data from a completely different region. Bottom line: You get more value and capabilities faster – and they are more resilient.

We have done a massive amount of work to successfully architect the Intune and the EMS services in Azure as true cloud services. The end result of this unique architecture is a huge benefit for your organization.

Windows 10 kommt…

Posted on Updated on

auch kostenlos Upgrade für Windows 7!

…schon bald, nämlich am 29. Juli! Terry Myerson, Microsoft’s Executive Vice President of Operating Systems, hat die frohe Botschaft heute in “Blogging Windows” in “Hello World: Windows 10 Available on July 29“ bekannt gegeben.


Wer Windows 10 schon jetzt in der aktuellsten Technical Preview testen möchte, kann dies auf https://insider.windows.com/ jederzeit ausprobieren.

Microsoft wird Besitzern von Windows 7 und Windows 8.x Lizenzen bis 29. Juli 2016 – also für die Dauer eines Jahres ab Verfügbarkeit – ein kostenfreies Upgrade auf Windows 10 anbieten, siehe Upgrade to Windows 10 for free.

Technisch ist ein “genuine” Windows 7 Service Pack 1 (SP1) oder Windows 8.x erforderlich um das Upgrade durchzuführen. Das Windows 10 Upgrade kann vorab mit der “Windows 10 App” angemeldet werden und man erhält dann ab Verfügbarkeit eine Benachrichtigung, dass das Upgrade durchgeführt werden kann.

Die App wird auf den oben angeführten Windows Betriebssystemen über Windows Update eingespielt und erscheint danach automatisch als Icon im System Tray rechts unten. Die Notifikation kann in den App-Settings auch ausgeschaltet werden.


Details zum Upgrade-Prozess finden sich auf Windows 10 FAQ.

Auch auf der BUILD und auf der IGNITE Konferenz gab es viele Vorträge zum Thema Windows 10.
Schaut doch mal rein: Channel9.msdn.com: Ignite Windows 10 Sessions.

Last but not least noch ein Hinweis zu unserem Event bei Microsoft Österreich in Wien, am 19. Juni:
Das neueste zu Windows 10 und anderen coolen Dingen – Zusammenfassung von //build und Ignite
Hier präsentieren wir die wichtigsten Neuerungen aus der Microsoft-Welt – von der Community  für die Community. Wir arbeiten noch an der finalen Agenda und freuen uns aufs Event!

Our favorite SCCM 2012 R2 SP1 New features

Posted on Updated on

Written by , Posted May 28, 2015.

Microsoft announced the release of SCCM 2012 SP2 and SCCM 2012 R2 SP1. This service pack includes tons of new features. We covered the complete installation, now we decided to compile a list of our favorite SCCM 2012 R2 SP1 new features and we’ll be describing how to enable them and explain why they made the cut.

Preferred Management Points

Official description from Technet : Preferred management points enable a client to identify and prefer to communicate with a management point that is associated with its current network location or boundary. When configured, a client attempts to use a preferred management point from its assigned site before using a management point from its assigned site that is not configured as preferred.

Basically it means that you can assign your clients to a preferred management points like you did in the past for content (Distribution Points) using boundary groups. Cumulative Update 3 had a similar concept of Management Point affinity but it was not configurable using boundary groups.

Prior to CU3, if you wanted to assign clients to a specific management point, a primary sites or secondary sites were needed as Management Points are not site aware. Stand-alone MP in your hierarchy was just giving your clients new management point to be assign but they were not forced to use them.

This feature could means simplified hierarchy for many organisation.

To use Preferred Management Points:

  • Open the SCCM Console
  • Go to Administration / Site Configuration / Site
  • Click on Hierarchy Settings on the top ribbon

SCCM 2012 R2 SP1 new features

  • In the General Tab, select Clients prefer to use management points specified in boundary groups and click Ok

SCCM 2012 R2 SP1 new features

  • Go to Administration / Hierarchy Configuration / Boundary Groups
  • Create a new boundary group or select an existing one and select Properties
  • On the Reference tab
  • You’ll notice that the text has been modified to add Management Points to the list of site system servers
  • Click Add and select your desired management points

SCCM 2012 R2 SP1 new features

All clients in that specific boundary group will now be using the selected Management Point.

Task Sequence Retry

Task Sequence logic has been modified to have the ability to configure retry options for when a computer unexpectedly restarts during the Install Application or Install Software Updates steps.

If you’re heavily deploying computer using OSD, you certainly remember the list of software update which requires multiple restart that made your SCCM Task Sequence to fail . Prior to SCCM 2012 R2 SP1, the task sequence step does not retry and cannot suppress restarts so the software update installation fails if a restart occurs.

This is now fixed, here’s how to enable this feature:

  • Open the SCCM Console
  • Go to Software Library / Operating Systems / Task Sequences
  • Right-click your Task Sequence and select Edit
  • Go to the Install Software Update step
  • On the right pane, select the Options tab
  • Select Retry this step if the computer unexpectedly restarts and specify how many times to retry after a restart

SCCM 2012 R2 SP1 new features

Automatic Client Upgrade

You can now exclude servers from automatic client upgrade. This is self-explanatory and it’s a nice addition for upgrading your clients.

  • Open the SCCM Console
  • Go to Administration / Site Configuration / Site
  • Click on Hierarchy Settings on the top ribbon
  • On the Automatic Client Upgrade tab
  • A new check box Do not upgrade servers has been added to exclude servers

SCCM 2012 R2 SP1 new features

Deployment Verification

Did you ever deployed a required task sequence to the All Systems collection? I hope not, Deployment Verification will help avoid human mistakes by defining a risky OS deployment.

You define a maximum size of a collection to be displayed/hidden when creating Task Sequence deployments. This feature only applies to Operating System deployment and it’s not possible for Packages and Applications.

  • Open the SCCM Console
  • Go to Administration / Site Configuration / Site
  • Right-click your site and select Properties
  • You’ll have a new Deployment Verification tab
  • Select the value for your maximum collection size and the action you want to do on collection that contains site system servers

SCCM 2012 R2 SP1 new features

  • Go to Software Library / Operating Systems / Task Sequences
  • Right-click a Task Sequence and select Deploy
  • A warning will prompt saying that your deployment is a high risk deployment

SCCM 2012 R2 SP1 new features

  • On Select Collection screen, you’ll notice that some collections are hidden based on the settings you previously configured

SCCM 2012 R2 SP1 new features

Import Driver

In order to improve driver management, the Import Driver wizard  has a new validation phase and new filters were created to hide certains drivers.

  • Open the SCCM Console
  • Go to Software Library / Operating Systems / Drivers
  • Right-click Drivers and select Import Drivers
  • Enter your UNC path to your driver location and click Next
  • The new validation phase is in progress
    • Note that this is painfully slow. I’ve tested this in 3 environments and enumerating my drivers takes up to 5 minutes. There’s a Connect Bug filled for this, upvote it if you’re having the issue.

SCCM 2012 R2 SP1 new features

  • Once the validation phase is completed you see the new filters and new UI which is much more intuitive

SCCM 2012 R2 SP1 new features

When adding drivers to boot images, you have the same filters which allows to hide non storage/network drivers and hide drivers that do not match the architecture of the boot image.

The grid view gives a much more comprehensive view without having to click each drivers to see their details.

  • Open the SCCM Console
  • Go to Software Library / Operating Systems / Boot Images
  • Right-click your boot image and select Properties
  • You see the new UI which gives more details about drivers imported

SCCM 2012 R2 SP1 new features

  • Select the star icon to add new drivers to the boot image
  • You see the new filters and new UI which is much more intuitive

SCCM 2012 R2 SP1 new features

Configuration Manager and Microsoft Intune

There’s so many new functionalities and changes in SP1 that we will create a blog post just for that. In this post we decided to talk about the Compliance Policy feature.

In short, Compliance Policy is Desired Configuration Manager for mobile devices without remediation possibility. Yes, you could already do DCM for mobile before SP1 but Microsoft decided to implement it as a new feature in SP1. Maybe a long term plan is to remove all mobile platform from DCM but that’s just speculation.

A major difference of Compliance Policy compared to DCM is that you don’t need to create a Configuration Baseline in order to deploy it. You create the Compliance Policy and you deploy it. Simple as that.

To create a Compliance Policy :

  • Open the SCCM Console
  • Go to Assets and Compliance / Compliance Settings / Compliance Policies
  • Right-click Compliance Policies and select Create Compliance Policies

SCCM 2012 R2 SP1 new features

  • On the General tab, enter a Name, Description, severity for noncompliance and click Next

SCCM 2012 R2 SP1 new features

  • On the Supported Platforms, select the platform and click Next
    • For our post, we’ll create a policy for Windows Phone

SCCM 2012 R2 SP1 new features

  • On the Rules tab, select the desired rules and click Next
    • For now there’s not as much option as in DCM, we choose to create a policy for passwords

SCCM 2012 R2 SP1 new features

  • On the Summary tab, review your settings and click Next

SCCM 2012 R2 SP1 new features

  • Once created, the only step left is to deploy your policy. Right-click your policy and select Deploy

SCCM 2012 R2 SP1 new features

  • On the Deploy Compliance Policy window, select your users Collection to deploy the policy, the Alert settings, the Evaluation Schedule and click Ok

SCCM 2012 R2 SP1 new features

There still tons of new features that we’ve not covered in this blog post. We’re still playing with mobile devices features and we’ll certainly make a part 2 post covering thoses.

That’s it for now, what’s your favorite SP1 feature ?

Managing Azure Active Directory joined devices with Microsoft Intune

Posted on Updated on

If you haven’t already seen it, Alex Simons just published a great post on Azure AD Join and the benefits it provides. In this post, I’m going to look at how to join Microsoft Intune and the Enterprise Mobility Suite (EMS) to Azure AD to light up some amazing scenarios.

I can’t even count the number of times I’ve talked to customers about a future scenario where they can finally tell their mobile end users: “Here’s a stipend, now go to an electronics store and buy a device for work.” Another variation of that discussion is simply sending a factory-imaged device from your OEM directly to the end user, and then through the power of an AAD account, the device can be business-ready in minutes.

Neither of these dreams have ever come about – primarily because todays devices have needed to come on premises to get imaged and domain joined. Because of the necessity of this on-prem step, IT has often had to buy and provision devices for the end user so that they can be properly managed and secured.  This adds up to some real costs and real delays in getting the device to the end-user.

At long last, that future scenario is – finally! – nearly here. By joining a Windows 10 device to Azure AD it is extremely easy for end users to get the benefits of single sign-on, OS state roaming, and more (see the aforementioned blog post from Alex for more details).

Another new (and incredibly powerful) part of joining Azure AD is the ability to automatically enroll the device in Microsoft Intune. From my customer visits I’ve learned that device enrollment is the single largest challenge organizations have in bringing mobile devices under management. Microsoft has worked exhaustively to dramatically simplify this process, and there is some great work that we have done in this area around Azure AD join.

Imagine how this can work for you:  Through the power and simplicity of a highly secure Azure AD account, users can immediately get access to corporate resources and the applications they need to be productive, while IT can be assured that those devices are secured for access (through Azure AD) and policy (through Intune) from the first minute of business life. Customers can also optionally choose to upgrade from Pro to Enterprise by simply passing a key through Intune. This means easily adding additional management (as afforded by the Enterprise SKU) simply by passing this key – there isn’t even a need to reimage!

Additionally, key access controls (like conditional access to e-mail, and OneDrive through Intune enrollment, and compliance assessment) are all assured from the start of a device’s life! All the user has to do is enter their Azure AD account. It’s just that simple.

Here are two key scenarios that are going to simply the lives of many IT Pros:

  1. New device out-of-the-box:
    Open the box and log in with your Azure AD account. This triggers enrollment into Microsoft Intune. Check out this blog for step-by-step screenshots of the experience.
  2. BYOD device:
    When the user needs to access a corporate documents or resources, they can add a workplace account. Doing this triggers enrollment into Microsoft Intune. This blog post has step-by-step screenshots and instructions.

Getting all of this set up is easy:


In the Azure AD administrative experience you just need to define:

  • MDM Enrollment URL for Intune so that devices know how to reach the MDM service.
  • MDM terms of uses URL which is your customized disclaimer that our end users see prior to enrolling their device into management.
  • MDM compliance URL which is the Intune Portal where end users go to remediate if their device is blocked due to Conditional Access policies.

I know what you’re thinking: “When should I consider joining Windows 10 devices to Azure AD?

The answer is pretty simple: It comes down to choosing between Azure AD join + Microsoft Intune versus AD join + Group Policy + System Center Configuration Manager.

In Windows 10, the inbox management agent has been greatly enhanced to cover a myriad of new policy settings, but it will be a subset of what on-premises AD Group Policy provides today.

I really like the approach Windows 10 took to smartly implement key policy settings via the inbox agent – and we also think that, for most customers, it won’t be an all-or-nothing decision. Instead, I expect it to be a choice based on the elements like the department, the specific job function, and other criteria.

Here are a couple of key questions to see if a device is right for Azure AD join or not:

  1. Do you have devices that only run cloud apps or apps being exposed through the AAD App Proxy? If so Azure AD join is optimized for these types of apps.
  2. Is the Windows 10 MDM/Inbox agent functionality sufficient for managing the device and its apps? For example, the apps on a device do not require AD group policy for configuration settings. As you become more familiar with the capabilities built into the MDM channel in Windows 10, you’ll be able to make the call if those capabilities are sufficient.

If you answer “yes” to these questions – for either a subset or all of your devices – then you’re likely ready to deploy and gain the benefits of joining Windows 10 devices to Azure AD and Microsoft Intune.

You’ll definitely want to become increasingly familiar with the new management and enterprise capabilities of Windows 10 (which are all exposed via the MDM/Inbox agent). Some of the new capabilities like Enterprise Data Protection, Certificate management, Lockdown policies, and Device Guard are exposed are particularly noteworthy. For organizations that are moving entirely (or mostly) to the cloud, AAD + Intune is a fantastic solution.

Many of you will want to apply these new capabilities along with the SCCM capabilities you’re already using. We have built the MDM/Inbox agent to co-exist and interoperate with the SCCM agent on the same device for this purpose. I suspect this is how many Enterprise organizations will operate.

More to come in the next couple weeks