#sccm2012

Now that we have our "application part" out of the way, it's time to tackle the rest which contains all other product and package details, such as: software architecture, language, package format, targeted platform, targeted department or service, ...etc. Again, since this should be equivalent to how your AppModel in SCCM2012 will look, this part should reflect your Deployment Types section. This part is a bit trickier: some of the package details are constantly required and some subject to exceptions, while others are rarely used particularly when it comes to targeted platform and targeted department. 2nd Folder Level: Let's start this off by covering the three main details that are always required and in order of importance (according to us): package format, software architecture and language. Keep in mind: we want to keep this consistant with the way SCCM2012 handles the different types of packages. Package Formats:

_Src: Keep a copy of your original software sources as they were provided to you

MSI: Anything Windows Installer, should it be MSIs, MSTs, MSPs and all associated cab files and external files that is triggered by a Windows Installer mechanic

AppV45: Anything concerning AppV 4.5. You want to keep a close eye to these packages, particularly knowing that you'll have to eventually convert them to AppV 4.6 or AppV5 because of compatibility / co-habitation existing only with Appv 4.6sp2 and 5.x clients

AppV46: AppV 4.6 sp2

AppV5: AppV5 (surprised?)

MISC: Everything else. Could be a batch file, a vb script, a command-line, a setup.exe followed with arguments ...etc

*exceptions: We did amend these by adding "-64" a few times during our last 18 months or work. This was mainly to differenciate between an x86 software installed on an x86 platform and that same x86 software installed on an x64 where existed some differences. Many of the Adobe products part of the CS5 / CS5.5 got in that category, although that corresponded to less than 1% of the lot (approx. yield: 2,000 packages). Software Architecture:

16bit: Yes, they still exist and you are sometimes doomed to make do with them. We also labelled as 16bit all products that even had as little as one 16bit component in them, such as a driver for instance. They're often the result of a lazy developer (did I dare say that?) that didn't look for finding / developing the equivalent x86 component. Again, try to have your customer upgrade this to an updated version of the software, and if not keep in mind that a Global Condition might have to be set as this product will most likely fail to install on a x64 box.

x86: Most of the programs we use today are still in this architecture, and will most likely work on a x64 platform - except if they have a 16bit component in them. You might want to consider labeling them as "16bit" if they are not compatible with your x64 targeted platform. Note: Some customers prefer to label this as "x32" instead of "x86" - which is absolutely fine as long as you are consistent using always the same identifier.

x64: Any x64 software. *Exceptions: We came across a couple of products (ie: McAfee) where the main launcher was a setup.exe which contained both x86 and x64 sources in them. The resulted category ended up being "x86x64". You could also choose to "duplicate" the source in this case and treat them as separate packages to avoid amending your naming convention, but then you'll have to support the evolution (patches, upgrades and removal / replacement) of 2 packages instead of just 1.

Language: This is the less understood category and brings constant discussions within an IT group. The application of this label should be adapted to your customer's culture. Do you list ALL languages available for a given software, or just the default language in which it is installed with? Do you want to let the users know if they can change the software language themselves by manually changing a setting in a menu, or if the software language changes automatically according to the OS UI (preferred UI language)? Nonetheless, this demands to sit with your customer and come up with the best strategy for this. Also keep in mind that very few IT dept. keep a high level of language details when it comes to software and, as perfect you would like this to be, it will be a hard thing to keep up with. In reference with that same customer I was previously talking about, we concluded that 90% of their staff work in French, more than 9% work in English and less than 1% work in a language other than French or English (Arab, traditional Chinese and Spanish). After going through their entire list of software, it became obvious that the way to go was gonna be:

Fr: For products strictly installed in French

En: For products strictly installed in English

ML-Man: For products that contain both French and English UI where the user can change manually the language UI himself

ML-Auto: For products that contain both French and English UI where the software UI follows automatically the OS "preferred UI language"

Ch: For products strictly installed in Traditional Chinese

Ar: For products strictly installed in Arab

Sp: For products strictly installed in Spanish

A forth optional token: We kept an ace in our sleeve with this naming convention, and we call it the "optional token". Put it simply: in case you have a package meant for a specific platform, specific department, a specific feature installed or else, this is where it should be flagged. We had the following previously identified should we need them:

WinXP: specific to be deployed on a Windows XP machine

Win2003: specific to be deployed on a Windows 2003 server

Win2012: specific to be deployed on a Windows 2012 machine

HR: specific to be deployed to people of the HR department

Accounting: specific to be deployed to people of the Accounting department

...etc.

As long as you get a short identifier thats explicit to what it's meant for. You get the idea. Again here, some of the same small tweaks that make it work better:

Avoid accents or special characters

Remove spaces and change every first letter of every word with an upper case . Use the underscore solely to differentiate Package Format, Software Architecture and Language (and the "optional token" when present)

As for the language, you might want to refer to a 2-character language standard to keep this tight

Putting it all together, these are the folders you'll see, in that specific order, if you look at what's contained in the WinZip_16.5_Corel top level folder:

_Src_x86x64_ML: in which we have a big self-extracting EXE file provided by rhe manufacturer which in turn has the x86, x64 and many language sources for WinZip v16. The leading underscore ("_") character make this folder show up at the top in alphabetic order.

AppV5_x64_En: AppV5 package in x64 software architecture and english UI language

AppV5_x64_Fr: AppV5 package in x64 software architecture and french UI language

AppV5_x64_Fr_Finance: AppV5 package in x64 software architecture and french UI language, specific for the Finance department which is installed in a way that WinZip encrypts solely in 128bit. Instead of putting "Finance" as the optional 4th token, we could have identified this as "128bitEncryption" instead.

AppV5_x86_En: AppV5 package in x86 software architecture and english UI language

AppV5_x86_Fr: AppV5 package in x86 software architecture and english UI language

AppV5_x86_Fr_Finance: AppV5 package in x86 software architecture and english UI language with that same 128bit encryption support described earlier.

1.  Complete the Base Configuration. The Base Configuration is the core of all Test Lab Guide scenarios. The first step is to complete the Base Configuration.

2.  Configure CM1. After installing the operating system, CM1 must be configured and joined to the corporate domain.

3.  Complete Installing SQL Server 2008 R2 Enterprise and Service Pack 2. System Center 2012 Configuration Manager requires SQL Server 2008 or 2008 R2 with the latest service 

pack.

4.  (optional) Complete the TMG Core Configuration. The TMG Core Configuration provides internet access to the Test Lab.

5.  Configure DC1. Several steps must be performed on the domain controller in preparation for System Center 2012 Configuration Manager.

6.  Install System Center 2012 Configuration Manager Prerequisites. Prior to installing System Center 2012 Configuration Manager , there are some prerequisites that must be met.

7.  Install System Center 2012 Configuration Manager. Install the System Center 2012 Configuration Manager binaries on CM1.

8.  Configure System Center 2012 Configuration Manager. Configure the roles of System Center 2012 Configuration Manager.

9.  Deploy the System Center 2012 Configuration Manager Client. Deploy the Configuration Manager Client to CLIENT1.

La guia completa lleva los paso a paso sobre la configuración sobre este escenario, una buena opción para hacer sus laboratorios de pruebas con Configuration Manager 2012.  Encontraran también los enlaces necesarios para descargar los productos para hacer el lab.