San Francisco Bay Area Endpoint Management User Group

 View Only
Back to Library

User Notes and Updates to Service Desk 7.1 Installation and Upgrade  

Jul 28, 2011 11:13 AM

I have almost finished setting up my Service Desk 7.1 and Workflow 7.1 install with a New SMP 7.1 install on a seperate server. I made notes (which you will find highlighted in yellow and green) to the Service Desk 7.1 Installation and Upgrade as I installed. Several of these notes are very important and the install will not work if you don't do these.

The SQL is on the SD 7.1 WF 7.1 server. I have updated the Service Desk 7.1 Installation and upgrade with three VERY important notes.

Without these notes my install failed. As I continue to polish my install in preperation for rollout to production I will publish new versions.

Statistics
0 Favorited
0 Views
1 Files
0 Shares
0 Downloads
​
Attachment(s)
pdf file
SD 7.1 Upgrade and Install Notes by SM ver1.1.pdf   1.81 MB   1 version
Uploaded - Feb 25, 2020
 
Download

Tags and Keywords

Comments

sdmayhew
Aug 11, 2011 12:38 PM

Since the Service Desk 7.0 install has really only been a test install with very little adoption in production. Their is very little data of worth so I wont be transferring this one.

toomas
Aug 11, 2011 12:25 PM

I apologize if my phrase usage and wording is almost as confusing as ServiceDesk documentation :)

Migration wizard is specifically for Helpdesk. That is - not for ServiceDesk.

Starting with a new clean database is always a good idea, especially with ServiceDesk, but at this time there is only one way to get incident data from ServiceDesk 7.0 database to ServiceDesk 7.1 - that is to upgrade the existing database. As there is no other way, this is Symantec recommendation.

If you have an alternative way of getting incident data from ServiceDesk 7.0 database to ServiceDesk 7.1, I would be extremely interested to know the details.

sdmayhew
Aug 11, 2011 11:50 AM

Toomas you seem to be contradicting your self in previous statement.

 

according to the docs - after everything is up and running use the migrate wizard. Again I am going on what I am seeing in the documentation and what things I saw in the upgrade

Basically you orphan the old SD 7.0 or HelpDesk 6.5 database. The incident data in it is migrated with the wizard after the install.

Their is a way to upgrade the old Ensemble database to a Process Management DB. It is not written correctly in the User guide on where to do this. I point that out and also that Symantec does not reccomend to do this.

 Altiris does not recomend doing a upgrade of the previous Ensemble database. Upgrade the CMDB using the SMP 7.1 wizard but not the Ensemble DB

I did not need to do this so I cant comment on actual workings on this.

toomas
Aug 11, 2011 10:07 AM

How do you migrate the incident data?

sdmayhew
Aug 09, 2011 11:36 AM

See more notes at https://www-secure.symantec.com/connect/forums/notes-new-install-service-desk-71-and-workflow-71

1 important one regarding sd.routingrules !

I still have not gotten 7.1 to install to my local machine- hopefully will have notes soon on that.

 

 

Toomas- I think you ment say that

Symantec recommendation is to NOT upgrade the existing 7.0 database.

 

Step 34A (Page 17):
If you want to upgrade your existing SD7.0 install this is where you put in the path to the restored Ensemble 7.0 DB. Symantec does not recommend this. They suggest doing a clean install and migrate incidents and workflows after install.
 
I still would object to this addition. There is no official/supported way of migrating incident data from ServiceDesk 7.0 database to a new ServiceDesk 7.1 database at this time.
 
Symantec recommendation is to upgrade the existing 7.0 database.
 
 

Migration User
Aug 08, 2011 02:58 AM

I installed our SD 7.1 last week and it took me the whole week to figure out all those details that you have mentioned to get the system successfully installed. Your notes solved the last problem I had with the workflow licensing (step 26A).

Great work! Thank You very much!

toomas
Aug 06, 2011 12:38 PM

 

I really like the work you've done with the comments and I believe it is done very well.
 
In practice, you've included a number of changes/suggestions that have usually been recommended only after some installation failure as a workaround/fix. All these errors do not occur very frequently but applying all those changes in the first place will preemptively help with the majority of known installation issues.
 
I still have some comments though (Page numbers are from content, not PDF pages).
:)
 
Page 2:
Service Account is the one that you will be using going forward as your Administrator Login ID
 
Wording can be slightly misleading, this will be the account everything runs with. Administrator User or login into ServiceDesk Portal will be different.
 
A little note on the service account and its rights in SQL Server - unless you have sa permissions for it, you may want to let ServiceDesk installer create the login/rights. We have only seen this with 7.1 a few times but it used to be a big problem in 7.0 installer :)
 
Step 18 (Page 11):
There is one thing that is missing from the guide (although it was there in ServiceDesk 7.0 MR2 guide), before changing the Application Pool accounts, I would say before the current step 18, run the following command line on the ServiceDesk server for the service account.
 
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -ga [domain]\[domainuser]
 
Note: The "[domain]\[domainuser]" syntax used by these instructions refers to specifying the domain name, backslash, then the user name of the specified account. For example: "Symantec\JSmith". The brackets and quotes should not be added.
 
Step 26 (Page 14):
Save the file to the desktop of the Server that will be hosting Service Desk. In my case this was my SQL server that only does Service Desk and Workflow.
 
Everything is correct, I have no objections to what you write, just a comment.
 
Symantec recommendation for a production ServiceDesk should get updated soon (minimum requirements will stay the same). They will include a strong recommendation to have a separate, dedicated SQL Server and separate disks in SQL Server configuration among other things. ServiceDesk does not play very nice with other things on the same server and running it with onbox SQL will require some serious hardware, very good management or both.
 
Step 26A (Page 14):
While you’re on the SMP server add the service account or Installation account that will be used in Step 33 to the Symantec Administrator account.
 
When you do this, please keep in mind that the credentials from SMP connection in ServiceDesk (or ServiceDesk installation) should be used in the same way as ther are entered here. For example, domain name format (FQDN/short).
 
Step 34A (Page 17):
If you want to upgrade your existing SD7.0 install this is where you put in the path to the restored Ensemble 7.0 DB. Symantec does not recommend this. They suggest doing a clean install and migrate incidents and workflows after install.
 
I still would object to this addition. There is no official/supported way of migrating incident data from ServiceDesk 7.0 database to a new ServiceDesk 7.1 database at this time.
 
Symantec recommendation is to upgrade the existing 7.0 database.
 
Step 40 (Page 20):
NOTE: At the time of this document, changing the Administrator Login password or name will result in a failed installation.
 
Symantec says this, yes. In ServiceDesk 7.1 installer, you can no longer change the Administrator User login/name. This recommendation is valid to ensure installation goes as smoothly as possible.
 
From my personal experience - I have not seen a single issue with actually changing either of these, in fact all my ServiceDesk 7.0 test servers have Administrator User account with login admin@sd.smc, so does my ServiceDesk 7.1 test box that was upgraded from 7.0 MR2. :)
 
Step 40 (Page 20):
NOTE: At the time of this document, selecting Active Directory for the authentication type may cause the installation to fail.
 
A comment on this: The reason for possible failure is simple timeout for larger AD environments (and real environments are mostly large). Going for AD Sync/authentication at installation can potentially time out and fail the installation while enabling this after ServiceDesk is installed is simple and straightforward.

Related Entries and Links

No Related Resource entered.