System Centre upgrade - fixed install paths in clients
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.
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.
ASKER
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
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
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\x
Or you may be able to add a Cname to DNS.
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\x
Or you may be able to add a Cname to DNS.
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 https://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
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 https://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
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.
Can we have an example of the path saved in registry please?
ASKER
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\S
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
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\S
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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...)
(Matt logs in to ConfigMgr test environment to explore...)
ASKER
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:
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
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
Thanks again.
Matt
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!
And don't forget to help your colleagues when they need it, that's the spirit!
Greetings from Greece!
In any case you can update the installation source in registry but it will take some work,