Test Lab Setup For Software Deployment Troubleshooting...

[anyweb]

these are the main guides, fyi, i'm sure it'll cover most of what you need for now...

 

http://www.windows-noob.com/forums/index.php?/topic/4045-system-center-2012-configuration-manager-step-by-step-guides/

[GarthMJ]

The only reason I'm really setting this up is to test deployment of our software package through SCCM.

 

 

Again, there is no need to setup CM12 to test your application and how it will deploy with CM12. Read the blog that I posted and it will give you what you need to simulate installing your application user CM12.

[anyweb]

hi Garth

that will only show him how apps can install using the system account it wont show him how to test the new features of the application model such as dependencies etc, so if simple application installation is all he needs it may be enough, but if he wants to understand how applications are created, targeted, deployed, managed, then he'll need a proper lab

[GarthMJ]

Hi Niall,

 

Based solely on their posts, there IMO is no indication that they want to learn about app model. So why complicate matter and setup as CM12 lab for "nothing", particularly if there is no need to do so?

 

The app model will NOT affect how their application will install (which is what they are looking for), it will only affect which deployment type is used to "install their application". We are also assuming that their are using the app model vs packages/programs. From what I have seem most 3rd parties are using packages/program in order to keep backward compatibility with CM07.

[Superfreak3]

Well, I do only want to test my application installation via SCCM. It that means I only need one machine (Server) to set up, great.

 

However, if there are multiple ways to deploy and .msi installation package, I would like to see or learn the different methods. If there are multiple ways to do this, I'm not sure what approach our end users are using. So testing any available methods would give a clearer picture as to what works and what doesn't.

 

If you haven't seen my issue already, here's a brief summary.

 

We have a 32 bit installation package that calls a 64 bit installation package near the end of its processes on that architecture. This all occurs via a widget that waits asynchronously for the 32 bit Windows Installer process to clear, then fires the 64 bit installer. In other words, the monitoring widget runs while the 32 bit install process goes on to completion.

 

What seems to be happening on some machines is that the 64 bit install package is not installing/running. What I think might be happening is that the 32 bit install completes and the SCCM settings contain a reboot. That would kill the waiting widget/64 bit install initiation.

 

I just want an environment to test various SCCM package configurations and how they effect our installation.

 

I'm not sure if that sheds light on what I might actually need by way of a test environment or not. I do want to learn as much about SCCM as possible, while not overburdening myself too much.

[GarthMJ]

IMO, you don’t need to setup CM12 just to test your setup. For learning yes, you need a CM12 lab but if you only want to test your setup then no there is no need for a CM12 environment.

 

Since this is a x64 vs x86 issue. I would create two VMs, one x86 and x64, Windows 7 or Window 8.

 

I would define your test plan first. Something like:

 

Using the local System account only.

• Run the Setup on x86 PC using x86 CMD
• Run the Setup on x64 PC using x64 CMD
• Run the Setup on x64 PC using x86 CMD

 

Which system are having problem?

 

Why not have two setup one for x86 and one for x64?

[Superfreak3]

Ah, great question and I have thought about it quite a bit. I would love to simply create a native 64 bit installer for a native 64 bit app, but we can't get there. Apparently we use a 32 bit toolkit of some kind that cannot be compiled for 64 bit.

 

There is fear of placing 32 bit application pieces in the native 64 bit file system as results may be undesirable - among other issues.

 

So, my solution is a complete hack to jump these hurdles.

 

The issue was only appearing on 64 bit systems and sporadically. The one company I was working with seemed to have a problem with one laptop. They did something to the laptop and all then worked so that may have been a machine issue.

 

Setting up the environment would enlighten possibly disprove my theories.

[Superfreak3]

OH, and we need the 64 bit piece for some third party apps we integrate with. They require some registry entries/files in native 64 bit locations.

[wilbywilson]

I'll agree with Garth on this one; you don't need a full lab to test out your packages/applications. Just build a few VMs (whichever operating system/architecture you want to test on), and get them into your SCCM environment. Then, make a collection within SCCM called "App Testing", which includes these specific VMs. Now, you can simply advertise your application/package to this collection, and test away.

 

This is actually common/best practice. You never want to deploy stuff in your environment without prior testing. And if you set it up as described, there should be no risk of affecting the "live" environment during your testing.

[anyweb]

when learning Configuration Manager having a lab to mess with is a wonderful thing indeed, that way you can test your theories without affecting production,

 

I've been to places where they've had the following setup

 

• Production
• Pre-Production
• Lab

 

and all three were separate

 

anyhow, if the poster wants to test via psexec, then sure why not, but i still think he won't get the information he needs that he'd get in a lab,

 

deploying test packages in a production environment is fine if you know what you are doing, but it's dangerous indeed if you don't.

 

One last point, when people google/bing this topic in the furture they'll find this link to setup a lab get confused about what to do..

 

the topic after all was "Test Lab Setup For Software Deployment Troubleshooting..."