So I just patched my ARSystem and wanted to share with everyone what issues I 
came across. Hopefully this will help someone else along the line.
I started off with a system 7.1 patch 002 and wanted to apply the latest patch 
level at this time, patch 007.

System:
ARS 7.1 Patch 002
ITSM 7.0.03 Patch 006
CMDB 2.1
Windows 2003 server
SQL 2005 Database
LDAP integration / SSO

Patch order:
Server.exe
Approval.exe
Assignment.exe
Emaild.exe
Midtier.exe

After applying the patches I noticed a few issues:
1.      Emails from the AR server were not going out to users.
2.      Very long lag time (4-5 hrs) of assignment notification s to support 
personnel.
3.      Request for approval notifications were not being generated.
4.      Mid tier not working at all.
5.      Users from other active directories not being created into People form.

The first issue was caused by an incorrect Application Service Password. When 
our version of Remedy was first implemented, I was not involved (as is the case 
with many new Developers/Admins) and passwords were not made available to me. 
When you patch the Email Engine, the setup will ask you for the Application 
Service Password. If this password does not match what you currently have set, 
you will have to change it later in the user tool.  Go to AR System Admin 
Console>System>General>Server Information>Connection Settings and change the 
password for Application Service Password to match what you set it to while 
applying the patch.

Second issue, the lag time was caused by 2 things. The first culprit was 
because I was doing the patching at night time to minimize user downtime. Most 
escalations run at nighttime and, as explained by BMC Support, some patches 
create escalations that run to update forms/fields/values. If there are other 
escalations, these escalations will get in queue. Depending on how long 
escalations run for the queue will get rather large and can cause other 
escalations to fire very late. Since escalations are used for assignment and 
notifications, they could be delayed. The second culprit of the lag time that I 
noticed was because most of my testing was conducted by assigning INC and CHG 
tickets to a support group called "Remedy". I did not know that this support 
group had its own Business Hours set. To check for these do the following: Open 
form "Support Group"> look for the specific support group> go to Business hours 
and Holidays. Check if there are any business hours defined.  These business 
hours, as the note on the tab says, "are used by the system (but not limited 
to) to determine notifications times, service level management actions, and 
time duration calculations". I simply deleted these hours to fix my issue.

Third issue, request for approvals not being generated. This was an odd one and 
I couldn't figure it out. While looking on BMC Communities, I found an article 
that after patching you have to go into each approval notification and make a 
change to each notification then save it. This will update the filters needed 
for the notifications. To do this open the AP:Administration form (from the 
Home Page if you're an admin) go to the Notification tab, click in the tab to 
display all notifications. Open each individual notification, go to 
Administrative Information, under Change History enter a comment (this could be 
anything, I used "Patch 007"), then click save. This action updates the filters 
AP:Notify-000000000xxxx. After performing these steps the notifications for 
approval requests were working.
Credit information: BMC Developer Network post # 81407 "Approval Notification 
message: donĀ“t send after install Approval 7.1 P004".  Solution provided by 
DavidR.

Fourth Issue, Mid-Tier not working. This was caused by the mid tier patch 
overwriting the folder called "com" from location ARSystem\Mid-Tier\Web-INF.  
It is a good idea to backup this entire folder in case you need it later. The 
patch will create a backup for you, but just to be sure. Simply copy and paste 
this folder back to its location and restart the server.

Fifth and last issue, our organization currently has 3 active directories 
(don't ask why). We have an LDAP integration which uses vendor forms to read 
each active directory and bring over, using escalations, user data. This data 
is used to create people in the CTM:People form. If a new user is created in 
active directory, the escalation picks it up and creates a user in Remedy. 
Because of the 3 active directories, our currently installation of the server 
is as follows: C:\Prog Files\AR System\Server. There are also 2 other folders 
setup as following: C:\Prog Files\AR System\Server-2 and C:\Prog Files\AR 
System\Server-3. This was done to accommodate 3 plugin.exe files. Each is used 
to access a different Active Directory. I guess you can say 3 plug-in servers 
are running. Well, the issue was that when I ran the Server.exe patch, it 
overwrote the armonitor.cfg file. This file contained the 3 different paths to 
each of the plug in servers. To fix the issue I had to open the armonitor.cfg 
file and add the lines:
"C:\Program Files\AR System\server\arplugin.exe" -i "C:\Program Files\AR 
System\server-2" -m
"C:\Program Files\AR System\server\arplugin.exe" -i "C:\Program Files\AR 
System\server-3" -m
After adding these lines, you have to copy the file arplugin.exe from the 
original install directory to the other two locations (in my case the original 
was located in C:\Prog Files\AR System\Server). Then, restart the AR System 
Server 'service'. Then check your vendor forms and it works.

Hopefully this will aid someone out there who is about to patch their ARSystem. 
 I have yet to patch ITSM, from what I've read, it is a bit more complex.

Marcelo Martinez

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"

Reply via email to