SC2012_SP2_Configmgr_SCEP.exe is all of the following
The full installation source for ConfigMgr 2012 SP2
The upgrade for ConfigMgr 2012 (non-R2) to SP2
The upgrade for ConfigMgr 2012 SP1 (non-R2) to SP2
The upgrade for ConfigMgr 2012 R2 to SP1
SC2012_R2_SP1_Configmgr.exe is essentially a feature pack upgrading ConfigMgr 2012 SP2 (non-R2) to "R2". This also changes the DISPLAY VERSION of the service pack to version 1. It does not remove any features or fixes (to my knowledge) but only the displayed version or marketing version of the service pack (from 2 to 1).
Prior to 2015/05/14 these versions existed
SCCM 2012 RTM (non-R2)
SCCM 2012 SP1 (non-R2)
SCCM 2012 R2 RTM
On 2015/05/14 these versions were added (these are my version names, not Microsoft’s)
SCCM 2012 SP2 (non-R2)
SCCM 2012 R2 SP1 (this could also be called SCCM 2012 SP2 with R2)
The confusion is really just a marketing issue. If the service pack were listed as version 2 for both product editions, this blog would probably never have happened. There would probably be some footnote somewhere that mentioned that SP1 for ConfigMgr 2012 R2 was skipped, and no real confusion would have occurred.
First, I’m not a networking guy so if this steps on some best practice please comment below on a better solution.
For a recent customer, a new domain (we’ll say contoso.com) was setup for both internal and external access. The customer found that employees within the company network were not able to access the contoso.com webpage without specifying www.contoso.com. Instead they were directed to a domain controller and thus a dead end. Obviously we didn’t want to install IIS on each DC just to redirect the traffic. Thankfully we found what looks to be a simple solution… port proxy at the server network interface level. So far the testing looks perfect.
Not long ago I was using MDT 2013 to develop a few images. Deploying from the server, whether booting from PXE, CD/DVD, or a USB drive worked fine. However, when I created a stand-alone ISO and extracted it to a bootable USB Hard Drive, the image deployment failed with the following error:
Script not found Unable to find LiteTouch.wsf needed to continue the deployment.
The error didn’t occur if I used the same ISO attached to a Hyper-V guest.
As I investigated I noticed that both the _SMSTaskSequence and MININT folders were not on the OSDrive, but on the USB drive. I found a few forum posts and blogs that offered DISKPART CLEAN as an option but this didn’t resolve my issue.
I eventually found some guidance from Keith Garner (MVP) that suggests that if a USB Hard Drive is larger than the target OSDrive, this error could result. I played around with partition sizes and a few other things but it made no difference. Only when I changed to a physically smaller USB drive was the problem resolved.
Apparently this “feature” was introduced in MDT 2012 and it still exists in MDT 2013. Hopefully this will be fixed in MDT 2013 Update 1 (or whatever the next version will be called).
A customer requested that I implement a solution to help keep their Active Directory clean of old/inactive Computer objects. While this is something I’ve done manually many times, I finally have a customer willing to automate the solution. As part of that exercise I wanted to write the “Previous OU” and some other data to the AD Computer object. I intended to use ExtensionAttribute15; however, I quickly realized that this attribute did not exist. As I discovered, ExtensionAttribute[1-15] are created by Microsoft Exchange which was not part of this environment. So, I needed a new field to store the data. Here is what I did.
Basic steps to create a new attribute and associate it to a Class / object
Logon to a domain controller with administrative and Schema Admin rights
Open a command prompt as an Administrator
register the Schema MMC snap-in by running regsvr32 schmMgmt.dll
generate the OID via PowerShell or VBScript
Open Active Directory Schema mmc snap-in
Right-click on the Attributes folder, and Create New…
Create an attribute for the Previous OU
Common Name: customPreviousOU
X.500 OID: <copy/paste from the script>.1
Syntax: Unicode String
Attribute is active: checked
Create an attribute for the Disabled On date
Common Name: customDisabledOn
X.500 OID: <copy/paste from the script>.2
Syntax: Generalized Time
Attribute is active: checked
Assigned the Attributes to a Class (object type)
Open the properties of Computer in the Classes folder
In the Attributes tab select Add and select the new attributes. Select OK to save and close.
The new attribute(s) can be viewed / modified in ADSI Edit or via a script. Below are a few PowerShell commands to view and modify the custom attributes.