There is a point of confusion currently in the System Center 2012 Configuration Manager product, and that revolves around fallback DP and how they get used.

The scenario is this.  You setup a content boundary group associated with 2 distribution points.  You put the content on all of them. You associate the boundary of a machine to that content boundary group.  What most people think is that the machine will get content from either of the 2 DPs.

Normally, this would be the case.  However, if some of those DP are marked as fallback DP, they will then be "bucketized" differently in the DP selection process.  If the application in question is not enabled for fallback then that fallback DP will not be offered to the requesting client and all traffic will be limited to only the remaining DP.

Here is an example scenario to help illustrate the current behaviour:

"We have two DPs:  DP1 and DP2.
DP1 has the option “Allow fallback source location for content” checked.
We have only one Boundary Group : BG1
BG1 has DP1 and DP2 as “assigned” site systems
Deployment type doesn’t have Fallback enabled (default option).

In that case, clients which ”belong”  to the BG1, will not use DP1 at all. It won’t be “offered” by the MP."

Put another way... watch out what DPs you mark for fallback.  The DP will either be a fallback DP, or a preferred DP.., but not necessarily both at the same time.

With Configuration Manager 2012 came a new UI.  It took some getting used to but I, for one, have come to like it over the old MMC interface.  There is one frustration with it that I hear from customers or see them attempting to workaround all the time.  ConfigMgr admins everywhere like to organize their applications, software updates, etc. into nice folders, for easy administration.  The downside of this is that when they or some other co-worker goes looking for a given application, they can't figure out which folder it is in.  Many folks ignore the search ability at the top of the UI window because it only searches the current folder, or root.

The solution is to look a little higher and to the left.  Up there and hidden among all the icons is a little button called "All subfolders".  If you are on applications, collections, software updates, and probably several other locations you should be able to find it.  The trick is that it doesn't show up initially.  You must click in the search box, then you will see it.  Some quick screen shots below, since a picture is worth a thousand words.

Every SCCM admin has figured out how to create a collection with a query rule to dynamically update its membership (you don't just do direct rules I hope).  Most admins have also learned that the columns able to be returned by a collection are limited but if you create a query in the Query node of the UI instead of under a collection you will have more control over what columns get returned.  Because of this it can be handy to run a query to bring back the info you are after, like a machine name and MAC.  You can't get AC under a collection, but you can as part of a query.

A piece of frustration kicks in at this point for most folks, and that is the fact that your right click options on a query can be.. missing a few things:

While I can't promise the solution to get every option to appear (I have been trying to figure out how to get a delete option to show up) I can share that the proper columns returned will provide ore right click options:

The UI can only offer options if it has the necessary data returned to make those options work.  Here is the query syntax to get more options to show up in your Configuration Manager console:

select distinct SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Client, SMS_R_System.Name, SMS_R_System.OperatingSystemNameandVersion, SMS_R_System.IPAddresses, SMS_R_System.SMSAssignedSites, SMS_R_System.SMSInstalledSites, SMS_R_System.Active, SMS_R_System.SMSResidentSites, SMS_R_System.MACAddresses, SMS_R_System.ClientVersion, SMS_R_System.NetbiosName, SMS_R_System.SystemRoles from  SMS_R_System

A much anticipated feature of System Center Configuration Manager 2012 (SCCM) was RBA (Role Based Administration, also known as RBAC or Role Based Access Control).  When this functionality was added to reports it was very welcomed, but also made life a little difficult.  When most people, myself included, are working out the syntax of a report we want to work in SQL Management Studio.  If you take an existing report and try to customize it you will find that it is making a call to a RBAC function based on the user's SID.  You may not have a user SID available easily so you could remove that from the query syntax or look up a test SID or something.  There is an easier way.

If you look at the RBAC function you will notice that there are some exemptions if the passed in value is "disabled".  If you simply switch to use "disabled" in your testing you can keep the function but get full results, then when you are done working out your SQL syntax change it back to "@UserSIDs".

As an example, if I want to mess around with a report I already I have I start with the following query which I can grab from report builder, but won't work in SQL Management Studio :

select SYS.Netbios_Name0, TCU.SystemConsoleUser0, SF.FileName, SF.FileDescription, SF.FileVersion, SF.FileSize, SF.FileModifiedDate, SF.FilePath
From v_GS_SoftwareFile  SF
join fn_rbac_R_System(@UserSIDs)  SYS on SYS.ResourceID = SF.ResourceID join v_GS_SYSTEM_CONSOLE_USER TCU on SYS.ResourceID = TCU.ResourceID
Where SF.FileName LIKE @variable
ORDER BY SYS.Netbios_Name0

For SQL Management Studio I use this variation to work from (also hard coding for another variable used in the query that is normally a prompted input):

select SYS.Netbios_Name0, TCU.SystemConsoleUser0, SF.FileName, SF.FileDescription, SF.FileVersion, SF.FileSize, SF.FileModifiedDate, SF.FilePath
From v_GS_SoftwareFile  SF
join fn_rbac_R_System('disabled')  SYS on SYS.ResourceID = SF.ResourceID join v_GS_SYSTEM_CONSOLE_USER TCU on SYS.ResourceID = TCU.ResourceID
Where SF.FileName LIKE 'cmtrace.exe'
ORDER BY SYS.Netbios_Name0

For those of you doing OS deployments with System Center Configuration Manager 2012 (I bet the same info below applies to the 2007 version but haven't tested it) you may have gotten into prestart commands to run a custom script or perhaps an HTA to better control and customize the deployment process for your environment.  I have a customer doing this and in the process they noted that there are actually two different places you can set the prestart command (also know as a pre-execution hook).  Depending on how your deploy your OS you may only have one place that will work for you, but what happens if you set different scripts in both locations?

Setting in WinPE

The first place you can set is on the boot WIM itself.  You specify a script source location and a command line.

This ends up making it into the TSCONFIG.ini that is in the root of the WinPE drive when it boots up and looking something like (command line is different because of the timing of my screen shots, but you get the point I hope):

[CustomHook]
CommandLine=dumpvar.vbs
Source=SMS10000

When the task sequence process runs it finds this TSCONFIG.ini and launches the script as desired

Setting during Boot Media Creation

The other option is to add the hook during creation of your boot media.

In this case, the package gets pulled from the DP and put into the boot media with the WinPE along with a modification of the TS variables so that on startup and reading the variables the value is seen and the hook will be executed.

So what happens if you set both?  Take your guess before reading on and see how smart you are.  I’ll give you a hint… I originally thought both scripts would execute..., and I was wrong.

The process SCCM goes through is to check the variables to see if the media had set them to have a hook.  If so… that is what executes and the fact that the TSCONFIG.ini has a value is ignored.  Only when the variable is unpopulated will the ini be checked and that hook will be executed.

8/6 update - Fixed an image display problem.  Screen shots and logs may not line up correctly on script names and such.  Sorry.