From time to time, you will need limit (or ‘lock-down’) the number of ports that are used for RPC – this might be to allow traffic through firewalls or for other reasons. In Windows Server 2008/Vista and later versions the default dynamic port range is 49152-65535. For Windows 2000, Windows XP and Windows Server 2003 the default range is 1025-5000.
There is a Microsoft article – http://support.microsoft.com/kb/154596 – this outlines how to do this with some registry value changes, for example if I wanted to limit ports to between 8000-9000, then the following adjustments would be made, followed by a restart:
reg add HKLMSOFTWAREMicrosoftRpcInternet /v Ports /t REG_MULTI_SZ /f /d 8000-9000
reg add HKLMSOFTWAREMicrosoftRpcInternet /v PortsInternetAvailable /t REG_SZ /f /d Y
reg add HKLMSOFTWAREMicrosoftRpcInternet /v UseInternetPorts /t REG_SZ /f /d Y
After testing this on a Windows 2008 R2 Server and looking at Network Monitor traces, I found that the source port was still in the 49152-65535 range. After reading http://support.microsoft.com/kb/929851, I ran the following commands on both source and target servers, then restarted:
netsh int ipv4 set dynamicport tcp start=8000 num=1001
netsh int ipv4 set dynamicport udp start=8000 num=1001
netsh int ipv6 set dynamicport tcp start=8000 num=1001
netsh int ipv6 set dynamicport udp start=8000 num=1001
After looking at Network Monitor traces after making these final changes, I could then see that the RPC dynamic port allocation range (both source and destination ports) was locked down to the specified ports.
I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.
I recently had a problem when I was trying to run a SCCM program (not application) that called a simple Windows command (the command was wbadmin.exe – but this is irrelevant) in SCCM 2012 on a Windows 2008 R2 64bit Operating System client. I noticed it was failing and in the execmgr.log there was a line stating “Running “C:Windows\system32\wbadmin.exe” delete systemstatebackup -keepversions:16 -quiet with 32bitLauncher” and also the Ccm32BitLauncher.log showed activity.
It was the old problem with 64bit file system redirection that I have blogged about previously.
I found a great article here – http://madluka.wordpress.com/2012/09/24/configmgr-2012-64bit-file-system-redirection-bites-again/ – that provide a batch file solution –
if the batch file is being run from within a 32bit command interpreter on a 64bit Operating System then the ‘Native’ 64bit command processor is called and re-launches the batch file. If it is already a 64bit command interpreter then the code jumps to the “:native” label and continues as usual.
So my batch file ends up looking like this, and the Program command line just calls the batch file:
IF "%PROCESSOR_ARCHITEW6432%"=="" GOTO native
%SystemRoot%\Sysnative\cmd.exe /c %0 %* Exit
wbadmin delete systemstatebackup -keepversions:16 -quiet
A bit messy but there aren’t too many other option in this scenario.
David O’Brien has created a fantastic PowerShell script that collects the configuration of your SCCM 2012 environment and exports it into a well formatted and comprehensive Word document. More information and downloads here:
Enhansoft have also just released their SCCM 2012 Documentation Script (SYDI-SCCM), this is available for free (after registration) from their website:
I’m often asked what the System Management container in Active Directory is used for. SCCM can use this container to store a small amount of configuration data for clients (or at least clients that are attempting an installation) can retrieve and use.
Configuration that is commonly stored in this container includes:
- Client computer installation and site assignment (eg installation properties like management points, client cache size)
- Port configuration for client-to-server communication
- Network Access Protection (validate a client’s statement of health)
- Content deployment scenarios (eg if you plan to create content at a primary site and deploy that content to a secondary site below a different primary site, you can use the container to obtain the source primary site’s public key)
A full list and much more detail is available from http://technet.microsoft.com/en-us/library/gg712272
Important information worth noting:
- Site Servers will only write their information into the System Management container in their OWN domain
- SCCM clients will query a global catalog to retrieve this information, so as long as they are in the same AD forest then they can query information from all domains, not just their own
- The System Management container needs to be created manually, it isn’t done by the SCCM setup process
- Permissions must be set manually on the System Management container. The primary site server computer account must be granted Full Control permissions to the System Management container and all its child objects. If you have secondary sites, the secondary site server computer account must also be granted Full Control permissions to the System Management container and all its child objects.
I’d like to do a quick post on something that I feel isn’t very well documented in SCCM 2012 – site assignment boundaries. Boundaries in SCCM 2012 are very different to previous versions not only because there are now ‘Boundaries’ and ‘Boundaries Group’ but because ‘site assignment’ and ‘content location’ are now separated and are configurable properties of a boundary group. For a one line definition of both of these, I quote directly from Microsoft (http://technet.microsoft.com/en-us/library/hh427326.aspx
- Site assignment = Site assignment is used by clients that use automatic site assignment to find an appropriate site to join, based on the clients current network location.
- Content location = Content location is used by clients to identify available distribution points or state migration points, based upon the client’s current network location.
I’ll put a statement out there that I have proven a number of times and I have had clarified by the SCCM product group and also Microsoft Premier Support as a working and supported configuration – ‘Given the right scenario, site assignment boundaries are NOT required to be configured in SCCM 2012‘.
To give this statement some context, I have worked in numerous multi-vendor, multi-region and highly politically complex organisations where one or more vendors or internal teams may use SCCM (2007, 2012 or even SMS 2003) as their support tool and it will need to co-exist with other SCCM deployments / hierarchies within the same environment (including same Active Directory forest). A new SCCM 2012 hierarchy can be deployed into these environment without affecting the existing environments and without breaking the SCCM golden rule that ‘boundaries cannot overlap’ (well, this is still partially true with SCCM 2012 – site assignment boundaries cannot overlap however content boundaries can overlap).
So if you are putting in a new SCCM 2012 hierarchy and you don’t want to reconfigure boundaries on existing SCCM hierarchies, on your new implementation simply:
- Untick the ‘use this boundary group for site assignment’ box for all of your boundaries groups, eg:
- Ensure you have the appropriate site systems added into the content locations section
- Ensure the SMSSITECODE=xxx installation property is entered into the tab in the Client Push Installation Properties, eg:
This way the client is hardcoded (for lack of a better word) to use a sitecode for site assignment (P00 in the above example) rather than trying to autodetect it, but the content location is still automatically and dynamically detected.
The impact of the above configuration on this new SCCM hierarchy is:
- Automatic site assignment will not be supported. SCCM clients will always contact their designated Site Server unless reconfigured.
- This hierarchy will not automatically support network roaming of SCCM clients.
- Automatic client push installation will not work however other installation methods including pushing from the console with the ‘Install Configuration Manager Client Wizard’ will still work
A few relevant notes:
- System Center 2012 Configuration Manager clients check the version of the Configuration Manager site before they complete site assignment and cannot assign to a Configuration Manager 2007 site if boundaries overlap. However, Configuration Manager 2007 clients do not check for the site version and can incorrectly be assigned to a System Center 2012 Configuration Manager site. (see client site assignment considerations in http://technet.microsoft.com/en-gb/library/jj822985.aspx)
- You will still need to ensure the pre-existing SCCM hierarchies are configured so they don’t try and push the old SCCM client to your new hierarchy’s clients
- This configuration assumes you use the client push wizard for client installation, obviously if you are doing manual or GPO client installation you will need to use the SMSSITECODE=xxx property too
- If you manually assign a client computer to a System Center 2012 Configuration Manager site code that does not exist, the site assignment fails. The client remains installed but unmanaged until it is assigned to a valid System Center 2012 Configuration Manager site.
- If you make a change to the site assignment configuration of a boundary group, only new site assignment actions are affected. Clients that have previously been assigned to a site, do not re-evaluate their site assignment based on changes to the configuration of a boundary group (http://technet.microsoft.com/en-us/library/gg712679.aspx).
And finally, a blurb from Microsoft (http://technet.microsoft.com/en-us/library/gg682060.aspx) on the basics of SCCM client site assignment:
After a System Center 2012 Configuration Manager client is installed, it must join a System Center 2012 Configuration Manager primary site before it can be managed. The site that a client joins is referred to as its assigned site. Clients cannot be assigned to a central administration site or to a secondary site.
The assignment process occurs after the client is successfully installed and determines which site manages the client computer. When you install the mobile device client during Configuration Manager enrollment, this process always automatically assigns the mobile device to a site. When you install the client on a computer, you can also assign the client to a site or you can just install the client without assigning it to a site. However, when the client is installed but not assigned, the client is unmanaged until site assignment is successful.
To assign a client computer, you can either directly assign the client to a site, or you can use automatic site assignment where the client automatically finds an appropriate site based on its current network location or a fallback site that has been configured for the hierarchy. After the client is assigned to a site, it remains assigned to that site, even if the client changes its IP address and roams to another site. Only an administrator can later manually assign the client to another site or remove the client assignment.