Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

• A complete guide to Wake On LAN for ConfigMgr 2007 and ConfigMgr 2012: https://blogs.technet.com/b/configurationmgr/archive/2014/01/28/a-complete-guide-to-wake-on-lan-for-configmgr-2007-and-configmgr-2012.aspx
• Sleep States for Wake On LAN: https://technet.microsoft.com/en-us/library/bb693821.aspx
• Ports: https://tricksntreats.wordpress.com/2012/05/15/fixing-sccm-wake-on-lan-wol/

1. Download the ConfigMgr 2012 PowerShell Right Click Tools
2. Download tools from https://psrightclicktools.codeplex.com/
3. Install the Right Click Tools
4. Download Wireshark from: https://www.wireshark.org/download.html
5. Install Wireshark onto the system you wish to capture the network trace

• Open Wireshark
• In Wireshark, select Capture and then Options
• In the Capture Options, select Capture on all interfaces
• Set the Capture Files (save location)
• Shut down any other applications that might cause network traffic to avoid their non-relevant activity from showing up in the network trace
• On the Wireshark Capture Options, click Start to start capturing traffic
• Once the packet capture has begun:

1. Locate the test machine in the ConfigMgr console
2. Right click the machine and use the PowerShell Right Click tools to perform a Wake On LAN function
3. Wait for the device to wake up, if it does not after 2 minutes stop

4. Deploy a package with Wake On LAN enabled to collection containing the test machine
5. Wait for the device to wake up, if it does not after 2 minutes stop

• Once you have completed these steps, then click the STOP button on the capture
• Once the data has been captured, select File and then Save As from the menu, save the file with a relevant name
• Filter the capture in Wireshark for WOL
• Double click an entry to look at its properties, check the port being used in the successful communications

• ConfigMgr 2012 default port for Wake On LAN is Port 9
• Commonly used ConfigMgr 2012 Wake On LAN Ports are 7, 9 and 12287
• The PowerShell Right Click Tools default port for Wake On LAN is 12287

• Test with several machines in different subnets with port 12287 configured in ConfigMgr for Port
• Test with several machines in different subnets with port 7 configured in ConfigMgr for Port

Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

With the release of Windows 10, there is going to be a change to the way the Operating System logs created and how we can view them.

For those of us who are supporting services like Configuration Manager and Windows Update Services to deploy Software Updates, this means a change to how we will look at the WindowsUpdate.log in Windows 10.
The WindowsUpdate.log is still located in C:\Windows, however when you open the file C:\Windows\WindowsUpdate.log, you will only see the following information:

In order to read the WindowsUpdate.log in Windows 10, you will need to either perform one of two different options.

1) Decode the Windows Update ETL files
2) Use Windows PowerShell cmdlet to re-create the WindowsUpdate.log the way we normally view it

I am going to go ahead and start with the PowerShell cmdlet option #2, as it is my personally preferred method.

Using PowerShell Get-WindowsUpdateLog:

1) On the Windows 10 device you wish to read the WindowsUpdate.log open PowerShell with Administrative rights (I prefer to use PowerShell ISE)
2) Perform the command "PS C:\WINDOWS\system32> Get-WindowsUpdateLog", you will see the following occur:

3) This will take a moment to complete, once done,  you will see on the desktop a new WindowsUpdate.log file

Please note that the newly created WindowsUpdate.log file from running the Get-WindowsUpdate.log command is a static log file and will not update like the old WindowsUpate.log unless you perform the Get-WindowsUpdateLog cmdlet again.
However, with some PowerShell magic, you can easily create a script that will update the log actively to allow you to troubleshoot closer to real time with this method.

For more information on the Get-WindowsUpdate.log cmdlet, please go here: https://technet.microsoft.com/en-us/library/mt238376.aspx

Decoding the Windows ETL files:

So the other option, is to directly decode the ETL files for getting the Windows Update information during troubleshooting. Lets go ahead and walk through this:

1) Download the public symbols, if you have never done this, you can follow these instructions: https://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx
2) Download the Tracefmt.exe tool by following these instructions: https://msdn.microsoft.com/en-us/library/windows/hardware/ff552974%28v=vs.85%29.aspx
3) Open an elevated command prompt
4) Create a temporary directory folder, example %systemdrive%\WULogs
5) Navigate to the folder containing the Tracefmt.exe and then copy it to the folder you just created (example copy Tracefmt.exe to %systemdrive%\WULogs)
6) Run the following commands at the command prompt you have open

cd /d %systemdrive%\WULogs
copy %windir%\Logs\WindowsUpdate\* %systemdrive%\WULogs\
tracefmt.exe -o windowsupate.log <Windows Update logs> -r c:\Symbols

For the <Windows Update logs> syntax, you will want to replace this with the applicable log names, space-delimited. Example:

cd /d %systemdrive%\WULogs
copy %windir%\Logs\WindowsUpdate\* %systemdrive%\WULogs\
tracefmt.exe -o windowsupate.log Windowsupdate.103937.1.etl Windowsupdate.103937.10.etl -r c:\Symbols

In the Enterprise environment, it is important to maintain control over your devices, while the "Get Windows 10" app is a great component for the home environment to help reserve and upgrade your Windows version (7, 8 and 8.1 Home or Professional) to the upcoming Windows 10 Operating system.

The "Get Windows 10" application can cause a stir in the corporate environment, there is however relief for those Administrators who wish to smite the application from their environment to ensure that it will not cause chaos.

Let's start off with the basics about the "Get Windows 10" application by reading the article "Get Windows 10 App" - What does it mean for Enterprise Environments". This article will cover the who, what, why and when with addition information linked to the Windows 10 FAQ.

Article: https://blogs.technet.com/b/charlesa_us/archive/2015/06/12/quot-get-windows-10-app-quot-what-does-it-mean-for-enterprise-environments.aspx

After you have read through this article and you understand the basics of the "Get Windows 10" application, let move on to how to remove it from your corporate environment.

On devices that qualify the application will appear in the System Tray as a white Windows symbol:

When clicked on this allows the user of the device to sign up for the reservation and auto installation of the Windows 10 Operating System when it is released.

Per the "Get Windows 10 App" - What does it mean for Enterprise Environments" article and the FAQ, this usually is not an issue in corporate environments, however it is often that such environments will have devices that run Professional versions of Operating Systems. Further in this day of mobile tablets, laptops and more while machines may be joined to a domain, they may stay out of touch from the domain for a very long time, this provides opportunity for the "Get Windows 10" application to creep into the corporate environment when not expected nor wanted.

There are three methods that you can remove \ block this application from your environment with a corporate solution in mind. We will cover each of these in this article.

The first I would like to talk about is blocking the "Get Windows 10" application by blocking the GWX.exe, this is the application itself.

If you were to take a system running the "Get Windows 10" application and open the Task Manager, you would see a process named GWX.exe running. If  you were to kill this process the icon in the system tray would be removed and also the ability for the system to auto upgrade to Windows 10 will be stopped.

Through the use of Domain Policy you can block this specific executable and prevent it from running.  Below you will find links to great TechNet Articles that cover these different methods to prevent the Executable from running.

For systems running Windows 8, 8.1:

AppLocker via Domain Policy: https://social.technet.microsoft.com/wiki/contents/articles/5211.how-to-configure-applocker-group-policy-to-prevent-software-from-running.aspx

For systems running Windows 7:

Software Restriction Policies: https://technet.microsoft.com/en-us/library/hh831534.aspx

The second method I would like to talk about is blocking the "Get Windows 10" application by Registry Key.

This method can be pushed out via Domain Policy or a ConfigMgr Package to devices. This section assumes you are familiar with the Windows Registry Editor and does not present knowledge on the Registry Editor Application.

In this method, you would perform the following steps to create a DisableGWX key under policies on the device, this would then disable the "Get Windows 10" application and remove the system tray icon as well.

The registry key path is: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows"

1. You will want to create a new Key called "GWX"
2. Select the new "GWX" key you created
3. In the right pane, right click and create a new DWORD named "DisableGWX" and set the value to 1

1. Once done, export the registry key and save as DisableGWX.reg

You can now take this registry key and deploy it to the client devices that you wish to block the "Get Windows 10" application on via Group Policy or a ConfigMgr package. Below are some great links to help with these deployment methods.

Deploying Custom Registry Changes through Group Policy: https://blogs.technet.com/b/askds/archive/2007/08/14/deploying-custom-registry-changes-through-group-policy.aspx

For ConfigMgr package deployment, this guide will not go into step by step for package creation and assumes you have familiarity with ConfigMgr Processes (Package Creation, Collection Creation, Deployments):

1. Create a Package in ConfigMgr

2. Set the Program for the package to the following:

• General:

1. Command Line: cmd.exe /c Regedit.exe /s DisableGWX.reg
2. Run Normal
3. After Running No action required

• Environment:

1. Program can run Whether or not a user is logged on
2. Run with Administrative rights

3. Deploy to a collection containing the devices

The third and final method  I would like to talk about is blocking the "Get Windows 10" application by deleting the task from Task Scheduler. That is correct, there are two Keys in Task Scheduler for the "Get Windows 10" application.

If you were to take a system running the "Get Windows 10" application and open the Task Scheduler (taskschd.msc). Then navigate to Task Scheduler Library \ Microsoft \ Windows \ Setup you will find under the setup key two more sub-keys.

• GWX
• GWXTriggers

Both if these keys are tasks to automatically launch the "Get Windows 10" application at intervals.

Both of these Scheduled Task keys can be removed via Group Policy and via Command line that you could deploy with ConfigMgr package. Below are two great links that will provide you information on using these two methods to remove the Scheduled Tasks.

Configure a Scheduled Task Item with GPO: https://technet.microsoft.com/en-us/library/cc725745.aspx

Creating and Managing Scheduled Tasks from Command Line: https://technet.microsoft.com/en-us/library/cc738335(v=ws.10).aspx

Further for ConfigMgr package deployment, this guide will not go into step by step for package creation and assumes you have familiarity with ConfigMgr Processes (Package Creation, Collection Creation, Deployments):

1. Create a Package in ConfigMgr

2. Set the Program for the package to the following:

• General:

1. Command Line: cmd.exe /c <Command Line Here>
2. Run Normal
3. After Running No action required

• Environment:

1. Program can run Whether or not a user is logged on
2. Run with Administrative rights

3. Deploy to a collection containing the devices

All of these methods are to remove and prevent the "Get Windows 10" App from running once it is on a machine. However, you will want to also assure that the KB Update that applies the "Get Windows 10" application is not being pushed out by your Current Patching Process either. The Update for the "Get Windows 10" application that installs it is "KB3035583".

Here is the KB article for the update: https://support.microsoft.com/en-us/kb/3035583

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

Multicasting was a feature added into ConfigMgr 2007 R2, that has continued support into ConfigMgr 2012. Multicast allows for image deployment with a much reduced network load in the environment. By utilizing multicast in ConfigMgr 2012, you can significantly reduce the network utilization. Normal deployment of operating systems in an environment with ConfigMgr 2012 OSD for a 500MB image to 20 devices would result in about 10GB of network utilization. However you take the same deployment and use multicasting and you now are going to see as little as about 500MB of network utilization to deploy the same 20 devices.

So, I am sure at this point you are saying, sign me up and how do I configure multicast?

If you are like me, you like to know the flow of how things are designed to work and the expected steps that should fall into that dance, with that said, I would suggest taking a moment to read over the "Planning a Multicast Strategy in Configuration Manager" article, you can find here: https://technet.microsoft.com/en-us/library/hh397406.aspx . This article will give you a good feel of the Multicast deployment process and a visual of how the flow should feel and look and knowing what good looks like is essential for troubleshooting.

So what are the requirements to have Multicast enabled in your ConfigMgr 2012 environment? You will need to have a site server with the following:

1) Distribution Point

2) Windows Deployment Services (required for the transport server)

You will also want to make sure that from a network stand point the following is true:

1) TCP Port 445 for Server Message Block (SMB) is not blocked

2) UDP Ports 63000-65000 for Multicast Protocol is not blocked

3) Network switches are configured for support of Multicast data transmissions

So lets get to it, go ahead and open your ConfigMgr 2012 Console:

1) Once you have the console open, navigate to "Administration \ Site Configuration \ Servers and Site System Roles". You will want to select the Site Server that houses the Distribution Point you plan to enable for multicast, please note this should be a Distribution Point that you use also for housing content for your Operating System Deployments as well.

2) Once you have the site server selected, look in the Site System Roles results at the bottom half of the console screen, select the Distribution Point so its highlighted.

3) Right click the Distribution Point and select "Properties" and once the "Distribution Point Properties" dialog window is open, select the "Multicast" tab

4) Place a check in the box next to "Enable Multicast to simultaneously send data to multiple clients"

When it comes to Multicasting there are two options available for sessions, first is "Autocast" and the second is "Scheduled". The difference between these two types of Multicasting is that when using "Autocast" you can add a machine at any time and it will join the session and start imaging. When using "Scheduled" the devices added to the session will hold until the "Minimum" session size (clients) is reached, once that is done the session will start the imaging process for the devices.

"Autocast" is enabled by the action of enabling Multicast on the Distribution Point by default, but to enable "Scheduled" sessions you would need to check the "Enable scheduled multicast" box on the properties dialog.

So lets break down a little more the difference between "Autocast" and "Scheduled" multicast session types before you go making that choice on which type you want to use, note you can change types any time you wish as well.

"Autocast"

In this configuration the multicast session starts as soon as the first machine powers up and requests the image.  As additional machines are also booted up for imaging they will 'join' the current multicast session already in progress and consume the remainder of the stream.  When the stream ends it will start again and the systems that joined late will consume the parts they missed.  While autocasting isn't as efficient as scheduled multicast it is still significantly more efficient that standard OSD image delivery.

"Scheduled"

Scheduled multicast allows for more control of the multicast session.  Here you choose either a time delay before starting the multicast session or a minimum number of clients that must join the session before it starts.  The multicast session will start whenever either of the two requirements are met.  The idea here is to allow the administrator time to get all of the systems started and ready and then all systems can load the image simultaneously - providing the best usage of network   resources. Scheduled multicast is enabled by selecting the 'enable scheduled multicast' check box.

Now that you have an understanding of the two different types of Multicast sessions, let take a look at the other settings on the Multicast properties dialog, those are "Multicast Connection Account", Multicast address settings" and "UDP port range for multicast".

Multicast Connection Account:

As you may guess this comes down to the account used to connect to the primary site database, during the creation of a new session or joining of a existing session, by a device via WinPE. This really comes down to your preference on if you wish to use the Computer Account for the Distribution Point that Multicast is enabled on or an Active Directory Domain Account. If you choose to use an Active Directory Domain Account you will want to assure the account has the rights to connect to the primary site database.

Multicast address settings:

This comes down to if you wish to allow the IPv4 IP address ranges to use any IP range in the environment or if you wish to restrict it limiting the field per say to only a specific range of IP Addresses. This is something you may want to talk out with your network administrator, DHCP administrator to determine this setting for your environment.

UDP port range for multicast:

This section allows you to configure the UDP port range, please note the default is "Start" 64001 to "End" 65000, the UDP port range is the range that your Multicast session will use for the UDP protocol communication. If you change this range, please assure the ports you change to are not blocked in your environment by working with your Security Admin and your Network Admin.

Now if you also notice under the UDP port range for Multicast, there are additional settings, "Client transfer rate" and "Maximum Clients", these settings can play an important role in the success or failure of a Multicast session. I would strongly recommend that when you are first configuring and testing Multicast in your environment that you start with the default on these two settings and then adjust during testing to find your stable "Maximum clients" setting and your stable "Client transfer rate". Setting the "Client transfer rate" too high or even too low in your environment can result in fragmented packages, failed sessions or even sessions that time out. If you find that after adjusting these, you are still getting some unstable results, one common solution is the refer to this KB article which is a Server 2008 R2 fix but still applies true in Sever 2012. You can find this article here: https://support.microsoft.com/en-us/kb/2582106

Now that we have covered the Multicast properties on the Distribution Point and configured the Multicast components, what else do we need to do? The next action would be to enable the packages you wish to support Multicast during OSD, please note these package types fall under the category of 'Operating System Images", "Operating System Installers, "Drivers", "Legacy Packages". To configure these package types you would perform the following for each package you wish to allow the Multicast support.

1) Locate the package in the ConfigMgr 2012 Console

2) Right click the selected package, and select properties

3) In the package properties, select the Distribution Settings tab

4) Place a check mark in the "Allow this package to be transferred via multicast (WinPE only)" box

Note there are two sub-options under the "Allow this package to be transferred via multicast" section, they are "Encrypt multicast packages" and "Transfer this package only via multicast", lets look at these.

Encrypt multicast packages:

Specify whether the image is encrypted before it is sent to the distribution point. Use this option if the package contains sensitive information. If the image is not encrypted, the contents of the package will be visible in clear text on the network and might be read by an unauthorized user.

Transfer this package only via multicast:

Specify whether you want the distribution point to deploy the image only during a Multicast session. Please note that if your Multicast session fails to create an you have this check box marked, your image process will fail as the package will not be accessible during Unicast which is the standard OSD deployment model and also what Multicast falls back to if it fails to create the session.

Now that we have the Distribution Point configured with the Multicast enabled and set, the packages configured to support Multicast, there is one last item to look at and you will be ready to roll with your first Multicast test! So the final ingredient for Multicast in ConfigMgr 2012 environment is to assure the Task Sequence itself is configured to support Multicast. We do this with east by assuring the Task Sequence is configured for "Download content locally when needed by running task sequence", see steps below.

1) Open the ConfigMgr 2012 Console

2) Navigate to Software Library \ Operating Systems \ Task Sequences

3) Select the Task Sequence you plan to use for deploying image via Multicast

4) In the Task Sequence results at the bottom of the console window, select the Deployments tab

5) Right click the deployment you wish to configure, select Properties

6) In the Deployment Properties, select the "Distribution Points" tab

7) Set the Deployment options to  "Download content locally when needed by running task sequence" and then click Apply and then OK

That's it - we are now ready to go for delivering images via multicast, however what logs could you use to monitor the progress of a Multicast deployment? I am glad you asked, ok well in my mind you asked, so lets take a moment to look at the logs as the last part to this article so you have a start to finish understanding.

Client Side of the house:

SMSTS.log: This is the standard go to log for troubleshooting Operating System Deployments, when you are using Multicast, this does not change. Its a very valuable log and will contain information regarding the request to create or join the Multicast session.

Server Side of the house:

MCSMSI.log and MCSSetup.log: Records details about multicast server role installation, this is a great set of logs, if you are troubleshooting the health of your Distribution Point with Multicast enabled. This would provide you details on the installation of the Multicast Point itself and indicate if any issues occurred during the installation.

MCSPerf.log: Records details about multicast performance counters, if you are seeing issues in your multicast sessions, this log will help you verify if there are any performance issues you should be concerned with.

MCSMGR.log: Records the SMS_MULTICAST_SERVICE_POINT component thread and will let you know if the component is healthy or having issues.

MCSIsapi.log: Records the HEALTHCHECK for the multicast component and the processing of requests from devices for Multicast session really important log!

Server Side Registry Key:

The following registry key is important to assure a healthy Multicast setup, if the key is empty, you will not be able to create multicast sessions. This key should be configured only a few moments after the initial installation (enabled) of the Multicast Distribution Point.

Registry Key Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\MCS

Registry Key: SignedSerializedMCSKey

A healthy Multicast Enabled Distribution Point Registry entry should look like this:

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

Recently, I have seen a growth in questions from customers regarding the "Get Windows 10 App" that has been showing up on Home and Pro versions of our Operating Systems. Customers are curious of how this will translate into the enterprise environment and what they may or may not need to do to prepare for this App just showing up. Below is the response to the common questions.

What is the "Get Windows 10 App"?
“Get Windows 10 is an app that’s designed to make the upgrade process easy. It checks to make sure your device is compatible, and it reserves your free upgrade; it also has information to help you learn about the features in Windows 10.

"Get Windows 10 App" Offerings (What should and should not be getting the App):
- We are offering to Windows Home Versions of Windows 7, 8 or 8.1
- We are offering to Windows Pro Versions of Windows 7, 8 or 8.1
- We are not offering for Windows Enterprise Versions of Windows 7, 8 or 8.1
- We are not offering for Volume License Machines
- We are not offering for Domain Joined Machines

How to disable the "Get Windows 10 App"
You can Click "Customize" in the System Tray and turn off the Get Windows 10 app notifications in the menu

Summary:
Want more information for "Get Windows 10 App"? You can check out the FAQ here: "https://www.microsoft.com/en-us/windows/windows-10-faq"

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

Section A - Ports

Before you configure the Source Hierarchy to start your Data Gathering, you will want to assure the following ports are open.

When gathering data the following network protocols and ports are used by Configuration Manager to communicate between the two systems.

1) NetBios/SMB on port 445 (TCP)

2) RPC (WMI) on port 135 (TCP)

3) SQL Server on port 1433 (TCP)

If any of these ports are not correctly configured to allow data travel, you will end up with Data Gathering issues.

Section B - Preparing the Source Hierarchy

You want to do this with the highest point in your existing ConfigMgr 2012 environment, (Example: In a Hierarchy with a CAS and two primary site servers you will want to specify the CAS as the source).

I also recommend following best practice to use the Configuration Manager 2012 R2 computer account for the migration account on the source. Why not use a regular domain account, you could but using the Computer Account, which is a Local

System account and has powerful access to the computer assures higher success rates for migrations.

(Configure the Computer Account in the ConfigMgr Console)

These steps are going to give the ConfigMgr 2012 R2 Computer Account the minimum permissions to migrate data from the existing ConfigMgr 2012 site.

1) On the Source ConfigMgr 2012 environment, assure you are on the highest point in the Hierarchy

2) Open the ConfigMgr 2012 Console

3) Navigate to Administration \ Security \ Security Roles

4) Right click "Read-only Analyst", select Copy

- On the Copy Security role dialog:

- Set the Name to ConfigMgr2012R2Migration

- Set the Description as "Role used for Migration to new ConfigMgr 2012 R2 Environment", Click OK

5) Navigate to Administration \ Security \ Administrative Users

6) Right click Administrative Users, select Add User or Group

- On the Add Users of Group dialog:

- Next to "User or group name" click Browse

- Enter the "Domain\ComputerAccount$" for the ConfigMgr 2012 R2 Site Server (Example: CONTOSO\CM12R2$), click OK

- Next to "Assigned security roles:" click Add

- Check the "ConfigMgr2012R2Migration" security role box, click OK

- Click OK

(Configure the Computer Account in the SQL Database)

These steps are going to give the ConfigMgr 2012 R2 Computer Account the minimum permissions to migrate data from the existing ConfigMgr 2012 site.

1) On the Source ConfigMgr 2012 environment (or remote SQL server if remote for that environment), Open the SQL Server Management Studio

2) Enter your credentials and click Connect

3) Click New Query

- Enter the following query: CREATE LOGIN [Domain\ComputerAccount$] FROM WINDOWS

- Execute the query, assure that you get the return of Command(s) completed successfully

4) Navigate to Security \ Logins

5) Select the "Domain\ComputerAccount$" you just added, right click and select Properties

- On the Login Properties dialog:

- Select User Mapping

- Under "Users mapped to this login", check the "CM_SITECODE" DB box

- Under "Database role membership for:CM_SITECODE", check db_datareader, db_onwer and assure public is checked, then click OK

Section C - Specify Source Hierarchy

Now that we have the existing ConfigMgr 2012 environment prepared, we need to create the Source Hierarchy in the ConfigMgr 2012 R2 environment to gather data.

1) On the ConfigMgr 2012 R2 site server, open the ConfigMgr 2012 R2 Console

2) Navigate to Administration \ Migration \ Source Hierarchy

3) Right click Source Hierarchy, select Specify Source Hierarchy

- On the Specify Source Hierarchy dialog:

- Set the Source Hierarchy to "New source hierarchy"

- Set the "Top-level Configuration Manager Site Server:" to the Fully Qualified Domain Name of the ConfigMgr 2012 Top-level site server name

- Under the Source site access accounts, select "Computer account"

- Under Specify the Source Site Database Account to use to access to the SQL Server for the source site server, select "Computer account", Click OK

4) You should then see the Data Gathering Status process on the screen

Section D - Migration Jobs

Now that you have completed the Data Gathering process, you are ready for the next phase of the migration which is to create a migration job

Below you will find an example of a package migration.

1) On the ConfigMgr 2012 R2 site server, open the ConfigMgr 2012 R2 Console

2) Navigate to Administration \ Migration \ Migration Jobs

3) Right click Migration Jobs, select Create Migration Job

- On the Create Migration Job Wizard dialog:

- Set the Name (Example Adobe Packages Migration)

- Set the Job type: Object migration, click Next

- On the Select the objects to migrate dialog:

- Select Software Distribution Packages

- Check the boxes for each Adobe product you wish to migrate (example Adobe Reader XI 11.0), click Next

- On the Assign ownership dialog:

- Set the top-level site server as the site you want to assign ownership (Example: CAS), click Next

- On the Security Scope dialog:

- Check the Security Scope you want to assign it to in the list, you can take default or create a custom security scope, click Next

- On the Settings dialog:

- Select Run the migration job now (default) or Schedule the migration job

- Select Do not migrate updated objects (default)

- Assure "Transfer the organizational folder structure for objects from the source hierarchy to the destination hierarchy" box is checked, click Next

4) Click Ok until you reach the Completion dialog, then click Close

The job will run now, unless you scheduled for a later time. You can troubleshoot and look for its progress in the "migmctrl.log" which will be created on the ConfigMgr 2012 R2 Site Server.

Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

This process will walk you through taking your existing Windows 8.1 Image and deploy it to a Surface 3 or Surface Pro 3 with a ConfigMgr 2012 R2 Task Sequence Stand-alone USB media.

This process is written for Surface 3 and Surface Pro 3 devices, while it can be used for Surface Pro 1 and 2 devices as well, it cannot be used for Surface 1 and 2 devices as they are only RTS models.

Section A - Preparation

- Make sure that your Windows 8.1 Image (WIM) has been tested before being used in this process

- Make sure you have downloaded the Latest Surface 3 \ Surface Pro 3 drivers from "https://www.microsoft.com/en-us/download/details.aspx?id=38826"

- Make sure you have at least a 16GB USB Thumb Drive

Section B - Drivers & Boot Images

Before we create the task Sequence Media, we need to first assure that everything is set right in the Boot Images for supporting the Surface Pro Devices

This article is going to take the stance of starting you out in this section at walking you through importing the Surface 3 \ Surface Pro 3 drivers into ConfigMgr 2012

(Importing Surface 3 \ Surface Pro 3 drivers)

Perform these steps on the ConfigMgr Site Server.

Assure that you have the latest Surface Pro drivers from here: "https://www.microsoft.com/en-us/download/details.aspx?id=38826" and expanded into a network share with read permissions for everyone.

1) Open the ConfigMgr 2012 Console

2) Navigate to Navigate to Software Library \ Operating Systems \ Drivers

3) Right click Drivers and select Folder \ Create Folder, name the folder, example: Surface_Drivers

4) Right click Drivers and select Import Driver

5) On the Specify a location to import driver,

 - Source folder click Browse and enter the UNC path to the share with the Surface Drivers in it, then click OK

 - Assure "Specify the option for duplicate drivers" is set to "Import the driver and append a new category to the existing categories", click Next

6) On the Specify the details for the imported driver,

 - Review the list of drivers to be imported, assure "Enable these drivers and allow computers to install them" is checked

 - Click the Categories... button

 - Click the Create... button

 - Set the Name, example: Surface_Drivers

 - Then click OK twice and then Next

7) On the Select the packages to add the imported driver,

 - Click New Package...

 - Set the Name, example: Surface_Drivers

 - Set the Path UNC path where you want to store the drivers, click OK

 - Assure "Update distribution points when finished" is checked, click Next

8) On the Select drivers to include in the boot image,

 - Assure all check boxes are clear (we will add them to boot images later), click Next

9) On the Wizard will import the following drivers, click Next

10) On the Import New Driver Wizard completed successfully, click Close

11) In the ConfigMgr 2012 Console, Navigate to Software Library \ Operating Systems \ Driver Packages

 - Right click the package you just created, select Distribute Content

 - Add the Distribution Points \ Distribution Groups

 - Verify that the distribution was successful

(Prepairing the Boot Image)

Perform these steps on the ConfigMgr Site Server.

These steps assume that you are already using the latest ADK (Example ADK 8.1 at the time of writing) boot images imported into your ConfigMgr 2012 R2 environment.

These steps are only going to be touching the Boot Image (x64) and not the Boot Image (x86) as you will want to use the Boot Image (x64) with the Surface devices.

Open the ConfigMgr 2012 Console

1) Navigate to Navigate to Software Library \ Operating Systems \ Boot Images

2) Select the "Boot Image (x64)", right click and select "Properties"

- Select the "Customization" tab, check "Enable command support (testing only)"

- Select the "Drivers" tab:

- Click the yellow star to add drivers

- Add the Surface Ethernet Adapter drivers, click Ok

- Click OK to update the boot image

3) Assure the process completes with zero failures

4) Wait until all Distribution Points are updated

Section C - Task Sequence

Before we create the task Sequence Media, we need to first create a new Task Sequence, this article will walk you through creating a base Task Sequence.

This Task Sequence will be set to "Join a workgroup" instead of "Join a domain" as this is a Task Sequence Stand-alone USB media and not assuming you have network access.

You can edit to add Applications, Software Updates, Etc.. at a later time to customize the Task Sequence further.

(Create the Task Sequence)

1) Open the ConfigMgr 2012 Console

2) Navigate to Software Library \ Operating Systems \ Operating System Images \ Task Sequences

3) Right click Task Sequences, select Create Task Sequence

- Select Install an existing image package, click Next

- Set the Name (Example: Surface Deployment)

- Click Browse to select the Boot Image (x64) you added the Surface Drivers to, click Ok and then Next

- Click Browse to select the Image package, select your existing Windows 8.1 Image, click OK

- Uncheck the "Configure task sequence for use with Bitlocker" box

- If not using a KMS Server, enter the Product Key and select the Service licensing mode

- Select "Enable the account and specify the local Administrator password" then set the password, click Next

- Select "Join a workgroup" and specify a workgroup name, example: "Surface Devices", click Next

- Leave the ConfigMgr client Installation properties blank for now, click Next

- Uncheck the "Capture user settings and files" box, click Next

- Select "Do not install any software updates", click Next

- Leave the Applications default, click Next

- Confirm the settings, click Next

- When completed creation of the task sequence, click Close

(Edit the Task Sequence)

Open the ConfigMgr 2012 Console

2) Navigate to Software Library \ Operating Systems \ Operating System Images \ Task Sequences

3) Right click the Task Sequence you just created, select Edit

- Select "Partition Disk 0 - UEFI", double click the "Windows (Primary)" partition in the list on right

- Set the "Variable" at the bottom of the Partition Properties to OSDISK, click OK

- Select "Apply Operating System", Set Destination to "Logical drive letter stored in a variable"

- Set the "Variable name" to OSDisk

- If you are using an unattended or Sysprep answer file with your existing Windows 8.1 image package

- Check the "Use an unattended or Sysprep answer file for a customer installation" box

- Click Browse, select the package and click OK

- Enter the file name

- Select "Apply Device Drivers", select "Limit driver matching to only consider drivers in selected categories:"

- Place a check mark next to the Surface drivers you created earlier

- Check the "Do unattended installation of unsigned drivers on versions of Windows where this is allowed" box

- Click Ok to apply and close the task sequence changes

Section D - Create the Task Sequence Media

Perform these steps on a ConfigMgr 2012 Remote Console, (Example your workstation), this is because most people do not have access to plug a thumb drive into the server.  You will need to plug your USB thumb drive into your machine at this time.

(Create the Task Sequence Media)

1) Open the ConfigMgr 2012 Console

2) Navigate to Navigate to Software Library \ Operating Systems \ Task Sequences

3) Right Click Task Sequences, select Create Task Sequence Media

- Select "Stand-alone media", click Next

- Select "USB flash drive" and select the Drive for the USB thumb drive, click Next

- If you want to "Specify a password to protect task sequence media" enter the password or uncheck the box, click Next

- Click the Browse button to select the "Task sequence" you created earlier, click Ok

- Check the "Detect associated application dependencies and add them to this media" box, click Next

- Select the "Distribution Point" in the top list you wish to use, click the Add button and then Next

- Leave the "Customization" page default, click Next

- Confirm the settings, click Next

- When completed, click Close

Section E - Summary

You now have a ConfigMgr 2012 R2 Stand-along media that will deploy your existing Windows 8.1 Image to Surface 3 or Surface 3 Pro devices.

A reminder that this process can be also used for Surface Pro 1 and 2 devices as well but not Surface 1 or 2 devices as they are RTS models.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Main System Center blog: https://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/

Data Protection Manager Team blog: https://blogs.technet.com/dpm/

Orchestrator Team blog: https://blogs.technet.com/b/orchestrator/

Operations Manager Team blog: https://blogs.technet.com/momteam/

Service Manager Team blog: https://blogs.technet.com/b/servicemanager

Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Microsoft Intune: https://blogs.technet.com/b/microsoftintune/

WSUS Support Team blog: https://blogs.technet.com/sus/

RMS blog: https://blogs.technet.com/b/rms/

App-V Team blog: https://blogs.technet.com/appv/

MED-V Team blog: https://blogs.technet.com/medv/

Server App-V Team blog: https://blogs.technet.com/b/serverappv

Forefront Endpoint Protection blog: https://blogs.technet.com/b/clientsecurity/

Forefront Identity Manager blog: https://blogs.msdn.com/b/ms-identity-support/

Forefront TMG blog: https://blogs.technet.com/b/isablog/

Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

Application Proxy blog: https://blogs.technet.com/b/applicationproxyblog/

The Surface Team blog: https://blogs.technet.com/b/surface/

Have a question about content? Join us on Yammer