Anonymous_User Absent Member.
Absent Member.
801 views

AppManager 8.2 migration


Hello,

Below some questions related to AppManager 8 migration
BEFORE : AM7.x with SQL Server 2005 SP4 and windows 2003
AFTER : AM8.2 with SQL Server Standard 2012 and windows 2012

After reading migration and upgrade guide as well as installation guide
I have 8 questions

1. Pre migration status
Current environment (All repositories are SQL Server 2005 with SP4 and
all O.S are Windows 2003)
14 QDBs : 7.0.41076.8
==> I must applied at least HX7011821 (latest HX7012493) on all QDBs
to be able to connect them to AM8.2
if I want to keep them in AM7.x to upgrade them later on an as-needed
basis (of course except Primary QDB)
CCDB : 7.0.41043.0
28 Management Servers (2 per QDB)
netiqms 7.0.41073.6
CQS 7.0.41077.30
6500 agents with 75% windows and 25% unix

It seems that only option in our case is to install a new CCDB and Prim
QDB to avoid an upgrade.
(to confirm that upgrade could be supported which is not really sure)

Just remind that the target is to migrate this environment to AM8.2 with
SQL Server 2012 and windows 2012

*Question 1: Does an upgrade is possible to AM8.2 by keeping windows
2003 and SQL Server 2005 ?*

Should be yes when Chapter 2 of migration guide explains how to move
AM7.x QDBs to be able to migrate to AM 8.x
we can find in page 25 windows server 2003 and SQL Server 2005 as first
supported environment for upgrade.
(SQL Server 2012 not supported in this case)

But I also found in migration guide page 20 "Only AppManager 7 Platform
update and 8.0.x " are supported versions for upgrade
I didn't check what "AM7 Platform update" is but it seems that even if
we have SQL Server 2005 and windows 2003 which are
supported in installation guide for AM82 that I can't upgrade my
environment because I'm not in "AM7 Platform update"

*Question n°2 : False or True ?*
*Question n°3: Can you please confirm that upgrade is not possible or
at least to avoid it with our complex architecture ?*
2. Step n°1 (AM8.2 environment by thinking that this is the only option
with our architecture)
Create a new CCDB and Primary QDB with SQL Server 2012 and 2 MSs
connected to PrimQDB with windows 2012 as operating system

*Question n°4 : Do I also need to create a new CQS environment in this
step ?*
*Question n°5 : What about CCDB and primary QDB in AM 7.X ? Is there a
migration process to apply on them ?*
Which process must be executed to have CCDB/PrimQDB information in new
environment ?
Does it mean that we need to move all agents, monitoring policy ....
from old environment and create them in new one ?

There are no real information in Upgrade and migration guide to manage
this case. (create a new environment because previous one can't be
upgraded)
*Question n°6 : Can you please clarify what must be done in this case
?*

We could think that we must do the following
a) Create CCDB/PrimQDB in AM8.2
b) Apply migration process on CCDB/PrimQDB in AM7.x from SQL Server
2005/windows 2003
to restore after in SQL Server 2012/windows 2012 ?
BUT possible only with AM7 Platform update which is not our case ....

3. Step n°2 (connect nonPrim QDBs)
Connect non primary QDBs to AppManager 8.2 (be sure that HX7011821 and
later has been applied)

4. Step n°3 (upgrade nonPrim QDBs)

*Question n°7 : To update a non primQDB we must apply setup process on
it but it seems that only server[instance], qdbname is provided
No target QDB. (as explained in page 48 of upgrade guide) As it seems
that our AM7 version is not supported
(as this is not an AM7 Platform update and 8.0.X), what can we do in
this case ?
Create again a new QDB with new MSs in SQL Server 2012/windows 2012 and
move agents 7.x to new AM8.2 environment ?*

*Question n°8 : Do I need first to move my AM7 QDBs to new SQL 2012
cluster and after apply migration process ?
(answer is NO based of what is written page 25 with only win2003/SQL
2005 and win2008/SQL 2008 supported to manage "migrating version 7.x
repositories")*

And target architecture is SQL Server 2012/windows 2012 to be able to
keep it few years as we work with our environment for a customer for
which we have a contract until 2017.

Many thanks
L.Geng - CSC (Computer Sciences Corporation)
NetIQ AppManager/NetIQ Aegis administrator


--
lgeng3
------------------------------------------------------------------------
lgeng3's Profile: https://forums.netiq.com/member.php?userid=5939
View this thread: https://forums.netiq.com/showthread.php?t=51915

0 Likes
1 Reply
Anonymous_User Absent Member.
Absent Member.

Re: AppManager 8.2 migration


Wow, those are some far reaching questions. My initial thought is that
this is probably too much information to handle fully and reply to
repsonsibly via a text post. However, there are definitely some initial
thoughts I can provide. First, for supported upgrades, you can always
find the information here,
https://www.netiq.com/Support/am/supportedproducts/default.asp. The
short answer is yes, AM 8.2 supports Win 2K3 and SQL 2K5. I would also
add some wisdom that my wife likes to give me: just because you can,
doesn't mean you should. Both of these products are no longer under
support by Microsoft unless you have a custom contract. It's a fair bet
that future enhancements (both from Microsoft and us) may well leave
your upgrade behind. If you're going to upgrade, go current: that's my
advice.

A further question you raise is about the versions of AM 7.0.4. If you
are running on 64 bit Win2K3 and SQL 2K5 now, then you must have the
Platform Update version (which supported installing on 64 bit systems).
In general, there are a couple of major methodologies for the upgrade.
You can either upgrade what you have or do a parallel upgrade. AM 8.2
is a huge leap forward from the 7.x version. This new version focuses
mainly on administrative overhead reduction. It offers so many new ways
to organize, manage, and secure AM that my basic site-unseen advice is
to go with a parallel install. Basically, install a new, clean 8.2
version, then migrate your agents into this new environment. This is
the vast majority of the work we do in Professional Services (my area of
work). The parallel upgrade is usually much cleaner and less work
because it allows you to set the stage for monitoring by staging
everything from KSGs to Management Groups (and Rules Based MGs are even
more flexible now too). AM 8.2 will support older version AM
repositories (QDBs), so you can even do a phased migration. The benefit
there is you start with less critical systems to work out the kinks,
then roll the rest into the new version.

So I realize that I didn't address every one of your questions
specifically, but I do hope I've given you enough information (and
gentle nudging) to make a decision about how to proceed. The last bit
of advice I have is to contact your Sales Engineer or even me directly
(dave.zucker@netiq.com) and let's talk about a Professional Services
engagement. My gut tells me that with these many questions, you may be
best served by a more in depth review of your current requirements. I
would not be surprised if we can help you decomplicate the entire
monitoring solution. The AM 8.2 upgrade is a perfect, natural launching
point to allow you to leverage the new capabilities. It becomes the
simplest way to remake your system without having to unwind any
complications or customizations that exist in the old system.

Best of luck and please let us know if we can help,

Dave Zucker
Principal Architect ITOM


--
zuckerd
------------------------------------------------------------------------
zuckerd's Profile: https://forums.netiq.com/member.php?userid=8273
View this thread: https://forums.netiq.com/showthread.php?t=51915

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.