I’ve recently spent some time with a customer deploying a large amount of Distribution Points in their ConfigMgr 2012 R2 hierarchy. They were finding themselves running into bottlenecks during the deployment, and with the help of the ConfigMgr Product Group, a new Site Control File property modification is now being supported.

Distribution point installations or upgrades may take longer than expected in System Center 2012 Configuration Manager

http://support.microsoft.com/kb/3025353 

The DPUpgradeThreadLimit property by default is set to five. The property should be carefully increased in environments where many Distribution Points are being installed/upgraded in parallel.

As the property is not visible by default, we need to create and set the new property. This will add the property and set it to the $newValue value across all of your Sites.

 This script is provided as-is and provides no warranties. Please thoroughly test in a lab environment, and see the Configuration Manager SDK for more information.

When I have a little downtime (which isn’t often!), I like to sit around and think of cool things I can automate using PowerShell. I have a .txt file that I put all these ideas into and every now and then have a crack at solving one.

Just recently I was playing around with Office 365 and Windows InTune and this idea struck me.

With the licensing model of Office 365 being user based, people are syncing their mail to more and more devices. They’ll have Outlook on their work laptop, email syncing on their Windows Phone, and probably syncing on their Apple and/or Android tablet as well. The problem with having so many devices is IT tracking and managing their corporate data. Of course, InTune is the obvious tool to manage these devices.

Getting your users to enrol their devices into InTune is one of the main challenges. As the registration has to happen from the end users side, I thought I’d write a script to help pester your users into registering their iPads, iPhones, Androids and WPs into your InTune MDM.

The idea is for this script to be run as a scheduled task. It will connect to your o365 tenant subscription and discover all those users who have synced their device with o365 since the last scheduled task ran. It will then send that user an email reminding them to enrol their device to InTune.

The email to your users can obviously be customized, but here’s a look at what I’ve given you by default

I’ve also added a testing mode switch, so you don’t spam your o365 users while doing your dev and test.

Here’s the script.

Matt Shadbolt

Hi All,

I had a need at a customer to write a script that would identify any active package distributions at a primary site via WMI. Although DPJobMgr will also give you more information and control this script returns a quicker result and in the case I was dealing with when you have a large number of active package distributions this can come in handy. Hopefully you'll find it useful.

The script is based on the SMS_DistributionJob Server WMI Class

(UPDATE. Matt just provided me with the following code that will give you your Primary site code automatically from WMI. thanks Matty.

##################################################

$providerLocation = gcim -ComputerName $siteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"

$sitecode = $providerLocation.SiteCode

$providerNamespace = "root\sms\site_" + $sitecode

###################################################

Updated script below

)

####################################################################################################################################

##Check the content distribution queue on a primary

$providerLocation = gcim -ComputerName $siteServerName -Namespace root\sms SMS_ProviderLocation -filter "ProviderForLocalSite='True'"
$sitecode = $providerLocation.SiteCode
$providerNamespace = "root\sms\site_" + $sitecode

$count = (Get-WmiObject -Namespace $providerNamespace -Class SMS_DistributionJob).count

$Activethreadcount = (Get-WmiObject -Namespace "root\SMS\Site_$($SiteCode)" -Class SMS_DistributionJob | Where {$_.Starttime -ne $null}).Count

$Activethreads = Get-WmiObject -Namespace "root\SMS\Site_$($SiteCode)" -Class SMS_DistributionJob | Where {$_.Starttime -ne $null} | Format-List -Property Starttime, RemainingSize

Write-Output "Total Current Active Distributions $($count)"

Write-Output "Total Active Threads Count $($Activethreadcount)"

Write-Output "Current Threads" $Activethreads

####################################################################################################################################

Feel free to post any updates or even scripts that you've written in the comments below.

If you want to look at other classes that could provide you with more information just check out the following MSDN reference

http://msdn.microsoft.com/en-us/library/hh948405.aspx

On the 7th of November 1994, a little product called Systems Management Server (SMS) 1.0 was released. Since that date, there have been four major revisions (SMS 2.0, SMS 2003, ConfigMgr 2007 and ConfigMgr 2012), three Service Packs (ConfigMgr 2007 SP1 & SP2, ConfigMgr 2012 SP1), three Rx releases (ConfigMgr 2007 R2 & R3, ConfigMgr 2012 R2) and countless Release Candidates/Betas, Cumulative Updates (CU’s) and Hotfixes!

I thought it would be really cool to check out the Wayback Machine for the TechNet page for the day that SMS 1.0 was released, but back then TechNet.com wasn’t even around! (how did we ever find our supportability numbers!)

The first mention of SMS on the Wayback Machine TechNet is in mid 2000 and talked about deploying SMS 2.0, administering Inventory and Software Metering, as well as the standard Server Sizing advice we all so heavily rely on. (in their Contoso sizing example, the Central Site with 14k clients required a server with a whopping 300-MHz processor and 256 MB of RAM!)

http://web.archive.org/web/20000817202621/http://www.microsoft.com/technet/sms/ 

(I love that the comments and suggestions hyper-link is a mailto:technet@microsoft.com)

I was fortunate enough to not have really dealt with SMS, starting my Systems Management journey with Configuration Manager 2007 but some of my colleagues remember those days well.

Sebastian Baboolal, Senior PFE at Microsoft

I started with SMS 2.0. SP5 back around 2004.

I was working for Microsoft support back then. We had one week of training and we were put on the phones.Classic trial by fire. My first call was a critsit for a customer. They had a large environment at the time > 100K clients being managed. They had a top-level SMS site. Then sites under that with lots of other primary sites under those. One of the 2^nd tier primaries went belly up. Had to do a DR on that site. We didn’t cover DR at all in the training (just my luck). Back then you had to go thru like 20 pages of stuff to get the site back up. I was on that call for 14 hrs. Did not leave my desk. We got it fixed but then I was thinking what in the world did I get myself into.
Glad we’ve moved on from CAPs and smsclitoken accounts but did like die_evil_bug_die and dial_me_in_baby

George Smpyrakis, Senior PFE at Microsoft

I started with SMS 1.2 back in 1997. I had just started in IT straight out of Uni and helped setup these Site Servers that seemed to take an entire day to complete. I took these boxes out to a couple of remote sites and got them up and running then started the long and arduous procedure of attempting to install the client on the workstations. At the time we used it as a  Remote control tool for the workstations and In the end it only lasted a couple of months before we removed it and that was a monumental effort in itself as the client seemed to never go away. A few years later a lovely virus called Nimda came along and brought the company I was working for to a halt. We literally had to go around the State of Victoria with floppy disks (Look it up for those under 30.) to patch each workstation so we could bring Internet access back. That’s when my Manager came up to me and said I want you to run with SMS so we never have to do that again. So I then Implemented and starting using SMS 2.0 and have never looked back…

Anthony Watherston, PFE at Microsoft

I started with SCCM 2007 implementing it because I had nothing better to do and looking to expand my horizons – some of my favourite memories.

• Reading through log files in Notepad until my eyes hurt – then discovering trace32
• The satisfaction of being able to remotely rebuild machines – we used to have people ship the box to us so it could be rebuilt
• Finally patching an enterprise – then fighting with people because they wouldn’t reboot their machines when patches were installed
• Releasing a hotfix to 180 secondary servers then watching as all the high impact tickets rolled in because all the site systems were reinstalling.
• Learning patience when installing new sites – sometimes things just take time to appear in the console
• Working all day on an issue – then doing a site reset and fixing it instantly

Through all this though it is one of the most complex systems management products and only limited by your imagination as to what you can do!

Russell Stevens, Senior PFE at Microsoft

I started with SMS (slow moving software) version 2.0 RTM in a distributed environment at a UK government department that may have had something to with mail in 2000…

Highlights include:

• SMSServer and SMSClient connection accounts for hundreds of Primary and Secondary sites.
• Software Metering ‘mark one’
• Switching from NT 4.0 domains to Active Directory domains (see point one).
• Restoring SMS 2.0 without a wizard, hours and hours and then monitoring for weeks and weeks.
• Preinst.exe became a useful companion from 2.0 -> 2003 -> 2007 –> 2012
• Seeing the feature packs become part of the Configuration Manager OSD\BDD, Software Updates (remember ITMU……..)
• Gigantic DDR backlogs.

It has been a great ride with some ups and downs, and has delivered some outstanding results over the 20 years, loved it.

So here’s to ConfigMgr! May our next 20 years be full of smooth CU upgrades, clear of inbox backlogs and void of all accidental deployments!

Matt Shadbolt

Many customers are still configuring collection structures similar to 2007 and using collections to control the validity of who should receive which applications.

Where possible we should be changing how we now manage application deployments and move the validity processing of the application back to the client by using our Global Conditions (state based) to manage Requirement Rules. This works well for many Off The Shelf (OTS) applications that do not have specific procurement constraints as we can safely deploy this category of applications to ALL USERS and if needed implement an Application Approval workflow. Where I am increasingly seeing customers still reverting back to specific targeted of applications, normally based of an AD Security Group, is for APP-V application deployments.

I continue to see a large uptake of APP-V in many customer sites as we move towards a user-centric mobile environment, which is great, however I am seeing a lot of customers experiencing poor publishing times of virtual applications which is often a result of poor administrative processes.

In SCCM 2007 we had the option to instruct the virtual application advertisement to auto remove the virtual application when the advertisement was no longer available to a client. Unfortunately this option is no longer available in 2012 and as a result many customers have gone searching for a solution by looking to the ConfigMgr Community forums. Unfortunately a lot of members of the community are simply recommending to use the general deployment rule that an INSTALL deployment takes precedence over an UNINSTALL deployment.  As a result many of the community forums have been instructing customers to simply create an UNINSTALL deployment for each virtual application and target this to the ALL USERS or ALL SYSTEMS collections. Please DO NOT DO THIS as you will continue to experience slow publishing times for APP-V applications.

If you are already doing this approach, I strongly recommend you read this blog to understand why this is a BAD idea and be VERY CAUTIOUS in your approach to undo this setup. DO NOT do a BIG BANG approach and remove all of the current UNINSTALL deployments in one hit and create the new recommended workflow as this will cause a huge amount of deployment policy objects potentially causing significant issues in your environment. It would be very advisable that you slowly stage the changes in your environment over a few days to prevent a mass number of policy changes in one hit.

When to use explicit collections for Tier 2 applications?

Only when you have specific LOB applications that require a REQUIRED Deployment.

• Valid Reason: APP-V Deployments where an automatic unpublished workflow is required

AGAIN DO NOT Target APP-V Uninstall deployments to the ALL USERS / ALL SYSTEMS collection as mentioned in many other forums. This will only delay your application publishing times and add unnecessary load on your ConfigMgr environment.

Understanding WHY this is BAD practice

When a client polls for new policy changes, a SPROC is run by the Management Point consuming SQL resources.

The more records in ResPolicyMap and DepPolicyAssignment, the more CPU time required to process the “GET” SPROC like

MP_GetMachinePolicyAssignments – Machine Targeted Deployments

MP_GetUserAndUserGroupPolicyAssignments – User Targeted Deployments

ResPolicyMap maps the resource ID and PADBID, (unique identifier for the policy). You can Query the count of ResPolicyMap objects to determine the number of policies being targeted to each user / system that must be processed.

DepPolicyAssignment links a policy object with its dependency polices and are provided to both users &/or machines when a policy request is initiated.

Examples:

• Application Requirement Rules defined
• Multiple Deployment Types per application

How you should mange APP-V Deployments in your environment

• Minimise the number of Required Deployments to the ALL USERS / ALL SYSTEMS Collections.
• Prevent making any large policy changes that target the ALL USERS / ALL SYSTEMS collections, or any large number of objects in one hit.
• Create an explicit UNINSTALL Collection for each REQUIRED Install Deployment.
• Base the Collection membership on the compliance state of the application = true and exclude the INSTALL collection.

Below are examples of the Collection Queries you can use to manage an auto un-publish workflow for App-V deployments based off an AD Security Group.

USER Centric Deployments.

1. Create an AD Security group for the application you are deploying.

2. Create an INSTALL Collection for each Virtual Application with a dynamic query linked to the AD Security Group. Target the INSTALL Deployment for each APP-V Application to this Collection.

2. Create a specific UNINSTALL Collection for each Virtual Application with a dynamic query using the syntax below. Also add an explicit EXCLUDE Collection membership rule that excludes the INSTALL Collection for that application. Ensure the application name matches that listed in the ConfigMgr database.

select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain
from SMS_R_User inner join SMS_G_System_AppClientState on SMS_R_USER.UniqueUserName = SMS_G_System_AppClientState.UserName
where SMS_G_System_AppClientState.AppName = "APPLICATIONNAME"
and G_System_AppClientState.ComplianceState = 1

Example

Create and Target the UNINSTALL deployment policy to the UNINSTALL Collection.

The result will be…. When a User is added to the AD Security Group the virtual application will be made available to the end user and install silently. When the user is removed from the AD Security group that has previously successfully published the APP-V application, they will be added to the UNINSTALL collection resulting in the virtual application being automatically removed from the client only then. This approach will minimise the ongoing policy objects that every user in the organisation will have to process.

Disclaimer: The queries and examples provided in this post are offered “AS IS” and should be used at your own discretion. Please ensure extensive testing be done before implementing this solution into any production environment. While this solution has been tested and confirmed, the ConfigMgrDogs team takes no responsibility for any unexpected results this may have in your ConfigMgr 2012 environment.…