Solved

System Centre upgrade - fixed install paths in clients

Posted on 2012-03-23
15
935 Views
Last Modified: 2013-11-21
I am in the preliminary stages of planning my migration from ConfigMgr 2007 to 2012 when it goes on RTM release. The current deployment is a single (virtual on Hyper-V) server of 2007 R2 in mixed mode which supports a workload of ~500 clients, 40 servers and 2000 or so users. We primarily deploy software to devices, but also use SCCM for OS deployment (XP and Win 7), Windows Update and FEP 2010. I need the VDI support in 2012 among other things so this will be an immediate upgrade as soon as I can.

I have a number of questions but my most pressing is what to do about my packages which are already deployed. We deploy MS Office via software deployment, which means the path to the DP is embedded as the network install path for Office into the registries of all the clients.

This poses a problem in the "configuring Office" process when Office is first run by a user.

How do others overcome this issue when upgrading your ConfigMgr deployments, changing servers and server names in the process?

In the past I have only ever resolved this by ensuring I migrate in such a way that the server, DP and package names don't change. This won't be possible with my upgrade to 2012 unless I migrate twice, which I'd rather not do.

Should I be using the "network install paths" setting in the OCT to specify a DFS share on which my office install files are stored? If so then the ConfigMgr upgrade is presumably going to require a redeployed Office package to apply this setting to all my clients?

Thanks in advance for your assistance.
0
Comment
Question by:tigermatt
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 4
  • 3
  • +1
15 Comments
 
LVL 23

Expert Comment

by:Nagendra Pratap Singh
ID: 37761106
Most software is downloaded and installed from cache. It should stay the same.

In any case you can update the installation source in registry but it will take some work,
0
 
LVL 58

Author Comment

by:tigermatt
ID: 37763757
npsingh123,

Thanks for getting back to me.

>> Most software is downloaded and installed from cache

Unfortunately, we don't use cached delivery. For a variety of reasons we install all but a few packages direct from the network source.

>> you can update the installation source in registry but it will take some work

Okay, I can see how that would work, but for every package, on every client, I'm going to have to make those changes?

That seems like a lot of effort to me. To have to roll out a change to every machine will require weeks of work, and will set this project back considerably. I'm only 500 clients, but I'm sure those running thousands and thousands of clients via SCCM wouldn't jump to such a solution.

Surely there is a better way I'm missing? Or is this an element of the the design of the SCCM infrastructure which is lacking? Should I have configured the packages differently in the first place so I didn't get this problem? (I think the answer is yes, and to nominate network install points which are not tied to SCCM or any particular server, but I would like your advice in that regard)

If I have to make changes individually on machines, I have so few machines that it isn't much effort to blow them all away and re-build them all from scratch, with suitably modified packages so I don't run into this problem again.

Matt
0
 
LVL 23

Expert Comment

by:Nagendra Pratap Singh
ID: 37763929
Roll out all packages to a single machine or at least some to a single machine.

Then add the sourcelist like this. I have added 4 servers in all.


MSIEXEC /I %MSIFILE% /L*V %MSILOG% /qb-! ALLUSERS=1 ADDLOCAL=ALL SOURCELIST="\\Winpkgsrc1\xpapps\%BaseAppLoggingName%;\\Winpkgsrc2\xpapps\%BaseAppLoggingName%;\\Winpkgsrc3\xpapps\%BaseAppLoggingName%;\\Winpkgsrc4\xpapps\%BaseAppLoggingName%"


Or you may be able to add a Cname to DNS.
0
Is Your AD Toolbox Looking More Like a Toybox?

Managing Active Directory can get complicated.  Often, the native tools for managing AD are just not up to the task.  The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.

 
LVL 7

Expert Comment

by:George Simos
ID: 37766561
Hi TigerMatt,

I believe you are aware that there is no in-place upgrade of ConfigMgr 2007 to 2012 right? That means you need a new server to host ConfigMgr 2012 and then you will migrate your data from the old to the new one.
However because the packages issues are numerous, microsoft has released the "Package Conversion Manager (PCM) for Configuration Manager 2012", check their article here for more http://blogs.technet.com/b/chrad/archive/2012/01/18/announcing-package-conversion-manager-pcm-rc2-for-configuration-manager-2012.aspx

Also you may be interested in my guide for the DFS shares usage as Software Repositories for Configuration Manager here http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Systems_Management_Server/A_5042-Guide-for-deploying-software-that-resides-in-DFS-folders-via-Configuration-Manager-2007.html
0
 
LVL 10

Expert Comment

by:Kezzi
ID: 37775955
For office, i would push out a pacakge that caches office to the machine (which is the better way of deploying office)  you specify the config.xml file to CACHEONLY and it will create the hidden MSOCache folder which office will look to for config changes.
0
 
LVL 23

Expert Comment

by:Nagendra Pratap Singh
ID: 37776115
Can we have an example of the path saved in registry please?
0
 
LVL 58

Author Comment

by:tigermatt
ID: 37778907
gsimos,

Yes, I'm aware of the lack of in-place upgrade, but thanks for pointing it out again. This is the source of my concern - I'm going to have to introduce a new server with a different name, and I knew this would cause issues! The package conversion tool is no issue from the server side; it's just all the clients with this wretched hard-coded path to the Office package which they seem to look to all the time.

Kezzi,

Thanks! I wasn't aware of the "CACHEONLY" option and may need to build that in to the deployment mechanism used for Office. More than half of our clients are based on XP and Office 2003; will this affect matters?

npsingh123,

>> Or you may be able to add a Cname to DNS

That's a solution I considered but it's pretty messy, and more like a hack than a decent way around the problem.

From memory, the path stored in the registry - at least on our Office 2003-based clients - is \\ServerM.<domain>.local\SMSPKGS$\<SiteCode>00035\PRO11.MSI. This appears to be accessed when a user's profile is yet to be configured for Office. On first run, the "configuring Microsoft Office" window pops up, and should the path above be unavailable for any reason, the whole process stops until the path becomes accessible again.

I'm very much of the mindset that a network should be server-name-agnostic, so I can change servers and so on at will. I hate hard-coding things like this when I can avoid it, so I will check in to your suggestions. A site-wide upgrade of Office was not on the cards, but we could co-incide a rebuild of every client and an upgrade to Office 2010 if it offers flexibility in the long run. That would all depend on when ConfigMgr 2012 is released, though (I can get ~2 weeks of downtime during our summer closedown).

-Matt
0
 
LVL 7

Accepted Solution

by:
George Simos earned 500 total points
ID: 37778958
Hi TigerMatt,

Recently I gave a training session for Configuration Manager 2007 and was asked about the client agent property of "Windows Installer Source Location", I wasn't quite aware of it because it was never needed but I think that this is for cases like yours, the
"Windows Installer Source Location Manager", please take your time and read it carefully because it will save you lots of time and frustration (hopefully).

In short words you add the paths for the locations of the source files of your software in the Windows Installer tab of the program's properties, when the clients update their policies they will use those source locations afterwards.
0
 
LVL 58

Author Comment

by:tigermatt
ID: 37779163
If that is doing what I think it's doing, then it's going to save me a LOT of hassle.

(Matt logs in to ConfigMgr test environment to explore...)
0
 
LVL 58

Author Comment

by:tigermatt
ID: 37779242
Hit the nail on the head! "Problem Scenario 3" is exactly what I'm trying to avoid. I can't believe I've never seen that feature before! But then, I'm more of an Exchange/AD person (excuses, excuses).

So, in theory, I'm envisaging that I am going to need to:

Run through the ConfigMgr 2012 upgrade process
Transfer my packages
Deploy a new client to the workstations
Ensure my Windows Installer settings are configured correctly in ConfigMgr 2012 so the new, correct path for the package is used on the new ConfigMgr environment is used by the clients

I'm pretty sure this has only ever posed a problem for MS Office and possibly our Adobe Design Suite packages but I'll probably just run through all the MSIs for consistency.

-Matt
0
 
LVL 7

Assisted Solution

by:George Simos
George Simos earned 500 total points
ID: 37779352
:-) Your procedure steps are correct, just a small change here, the App Model (the new Application Model of Configuration Manager 2012) has numerous differences in comparison with ConfigMgr 2007, for example there aren't any programs but conditions (global and application specific) etc
Do a bit of research for it just to be on the safe side.
Updating your packages is mandatory if you don't want to pull your hair later :-p
0
 
LVL 58

Author Closing Comment

by:tigermatt
ID: 37779767
I could not have asked for a better, more detailed and considered answer. It's not very often that I'm on this side of the Q&A process, but gsimos has made this experience very rewarding. My problem was understood and a solution proposed which is exactly what I was looking for. I will check in to all the changes with ConfigMgr 2012's app model to be prepared for the switchover when it happens!

Thanks again.

Matt
0
 
LVL 7

Expert Comment

by:George Simos
ID: 37781813
Thanks for your nice words Matt, my full name is George Simos, I will happily help you again!
And don't forget to help your colleagues when they need it, that's the spirit!

Greetings from Greece!
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

While rebooting windows server 2003 server , it's showing "active directory rebuilding indices please wait" at startup. It took a little while for this process to complete and once we logged on not all the services were started so another reboot is …
This article explains the steps required to use the default Photos screensaver to display branding/corporate images
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

733 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question