Is Service Desk 7.1 SP2 out?

[MRenfrow]

I saw the documentation on the web site for this but I cant find out where to download it. Also, can you upgrade from 7.1 SP1 to SP2 and all workflow customizations will come across?

[toomas]

ServiceDesk Solution in SIM. As documentation is up, expect it to be there any time now.

No, upgrade still needs re-applying customizations.

[JJV]

SP2 is released, at least on my sim

[sdmayhew]

upgrade still needs re-applying customizations.

 

that really sucks and is really silly if this is a service pack. Reading through all the release notes it looks like a major upgrade as some of the structure has changed. 

[Migration User]

Same boat here...was hoping you could just lay down the SP2 upgrade and happily have SD+Workflows come across with it. Ugh...

[Migration User]

It's really hard to manage any customizations done to customer flows and have them migrate "auto-magically". However, Workflow does ship with a "difference tool" that can identify differences between workflows. You can access it via Workflow Manager - Tools - Compare Projects.

[Migration User]

So, what are the steps you actually take for upgrading to SP2 with SD/Workflow? I already have all of my custom workflows backed up offline. They are exact copies of what is in production.

Do I just do the SP2 upgrade and then re-publish all of those custom workflows? What about other customizations that were done (Service catalog, Servidesk settings, etc.)?

[sdmayhew]

I would say this is a misnomer on symantecs part. the workflows should work as long as the components have not been renamed. If any component has been renamed it should be called out in the release guide 

[toomas]

ServiceDesk comprises of Workflow and a number of projects, while Workflow upgrade is straightforward, projects aren't that simple.

sdmayhew, the projects will work. You can of course publish your modified earlier version projects into 7.1 SP2 ServiceDesk, but basically we won't really guarantee it'll work as expected if half the projects are 7.1 SP2 and rest of them some earlier version.

There is always the option to upgrade only Workflow underneath your ServiceDesk but then you will still miss out on any fixes/enhancements in the projects themselves (and there usually are quite a few).

Service Catalog, ServiceDeskSettings and a lot of other things are saved in the database and will still be there after the upgrade.

Whether it is a desireable or undesireable way to upgrade is a different matter but this has been the way this has worked in all ServiceDesk versions starting from 7.0.

[Migration User]

Is there a way to know wich projects were updated?? I work with a Symantec Partner and have implemented 6 Service Desk server with different clients, so lots of customizations in place for this clients and it will help to know what to update.

I have done some updates from 7.0 to 7.1 SP1 and it was really hard work.

[Migration User]

Hello Guys, I'm in the same issue than Charles. It will be awesome if symantec team can tell if there is a plan for a tool to migrate those customizations or not to get this established and start to migrate.

Personally, I don't want to update right now, I'm better waiting for more documentation and testing but some of my clients wants the upgrade now.

[Migration User]

The workflows are one thing, but what about the incidents, KB’s and documents? For me it looks like you cannot connect to the exciting database but you have to create a new one. Do you start on scratch?

[Migration User]

I cannot believe that you are responding to great customer feedback of the pain (and expense) they are feeling with "this is the way it has worked since..." I am fighting a battle to keep the entire Symantec Management Platform based on our organization's extreme disatisfaction with ServiceDesk. Defensiveness is not the answer. We need a working, stable, manageable product with the ability to easily search old incidents. We need a product that allows us to apply service packs without extended consultanting engagements. I understand that these things take time, but the dissatisfaction has been there since 7.0. We need communication that this product is going to get very much better and fast.

[Migration User]

That's what I got from the release notes, too. Is this true? New database --throw out the old, including data?

[Migration User]

No hang on, I don't see anywhere in the release notes where an upgrade won't work. It does say that an in-place same-server upgrade isn't supported but that's because the workflows would be overwritten. I did an upgrade on my test server and things seem to be working fine. You can't choose the Upgrade button during the install, you must choose "Install" with the Advanced option checked to allow you to modify the service account info for off-box sql installations but it will allow you to upgrade the database itself.

The time-consuming part is to then modify the workflows to match current production. A few things I have found doing this process so far:

1) A traditional "upgrade" may never be possible as long as we are allowed to modify workflows. Even Symantec has made many changes from old to new so some of the modifications that were made by us may no longer be necessary and since there are so many different ways to accomplish the same tasks it is simply not manageable

2) Keeping an older version of Workflow Manager around with the old workflows is a good idea in order to compare new to old.

3) Detailed notes and documentation on what has been done are extrememly important and keeping a set of those notes OUTSIDE of the workflow is a must...if you accidentally upgrade and overwrite those workflows and the notes were inside, the notes are gone too.

[Migration User]

Agreed. My company is just in the process of deploying ServiceDesk but if this is how Symantec releases updates and their general stance on the subject, we are being forced to re-evaluate whether or not it makes sense to use it or switch to something else.

[toomas]

Jpellet2, with ServiceDesk 7.1 SP2 in-place upgrade simply won't work even if customizations are not considered. Basically you will lose at least some functionality and most likely open incidents will be unworkable. Usually there are more issues but these tend to somewhat vary.

The rest of your post is exceptionally good and valid though :)

While documentation (in the form of implementation guide) does not say anything about a new install using the old database, this is currently not supported. We have been communicating this stance since SP2 was released.

Note that the following is specifically about the Workflow upgrade on ServiceDesk server, we are not aware of issues with Workflow Server upgrade. We are now seeing that upgrading Workflow to 7.1 SP2 underneath ServiceDesk 7.1 SP1 (as Workflow upgrade for ServiceDesk has been possible and has been rather widely recommended before) is also not an option. Again, when doing that you seem to lose some functionality and open incidents will not be workable.

As laconic as they are, these two KB articles summarize the current situation with ServiceDesk 7.1 SP2 and upgrade:

• Is there an upgrade path from older versions of ServiceDesk to ServiceDesk 7.1 SP2? (TECH178051)
• Migrate existing ServiceDesk 7.0 MR2 & 7.1 SP1 closed incidents to ServiceDesk 7.1 SP2 (HOWTO61259)

[Migration User]

This is getting ridiculous then. Symantec calls this SP2 which would tell me that its a service pack for an existing product but then tells us that we can't actually upgrade the existing product at all! How is that a service pack! So basically now I have to fund a new server to install this "Service Pack" version of servicedesk. Create a new database, modify any and all customizations from the previous version into the new version (which I expected to have to do anyway) and then use a sql script to migrate closed incidents from the old DB to the new one. All the while, our helpdesk techs will have to use 2 different servers to work incidents, the old one for anything open and pre-exisitng and the new one for any new work and if our clients want to look up tickets then they too need to be pointed, somehow, from one place to another.

And is there anything to take into account all of the migrated incidents from Helpdesk which are SDM- and not IM-? I know the HOWTO says that we could modify X and Y to make it work but that seems like pretty poor customer service in my eyes. If Symantec supports that type of migration (HD to SD) then they should outright create scripts to move those same incidents around if something like this horrible upgrade is required.

I would also like to see an actual document or large section of the implementation guide be dedicated to the best practices to do this type of "upgrade". The implementation guide doesn't mention how to do this at all and I have yet to see a document that actually tells us how to do it.

I used to be a champion for this product and of the Management Platform but between this ridiculousness and issues that on the NS that Symantec doesn't want to help fix I don't know how much longer I can take it.

[Migration User]

Toomas, I know I vented a bit but can you see where the confusion and issues might lie in an environment where we have to spend thousands of dollars on the product, thousands of dollars for severs because of the extrememly steep requirements for performance, etc and then find out we can't upgrade.

Also, this document, although not specifiying SP2, was created on December 13 of last year and it says in the top paragraph that an upgrade can be done. http://www.symantec.com/docs/HOWTO61566 so how are we supposed to know what to do and how to do it if A) Instructions are not clearly presented and B) what content exists contradicts each other?

[Migration User]

Regarding TECH178051...

That is a big pill to swallow. We are already getting beat up for performance issues in SD and now after reading that tech article about SP2...we are going to get murdered by our technicians. They already despise the product and now this???

I'm with jpellet2 when he says he used to be a champion for these products, but now...how do we stay positive about it?

[Migration User]

We haven't even mentioned the other things. If we need to build a new server with a new DB, what about moving documents, knowledgebase articles, folders, permissions, custom groups, email settings, etc.? These items alone could take some places hours to recreate. If there are knowledgebase articles out there that refer to all of these things and the requirements are as stated earlier for this "upgrade" then shouldn't there be an actual upgrade guide with everything covered? In the least one single HOWTO with all of the components referred to so that we as IT administrators can have to use as a tool or to at least have when Management starts to question what needs to be done. At least give us something that we can point to and say Symantec is making me do this and is making us spend the money and the time and perhaps even client satisfaction and loyalty when they have to suffer through more changes yet again.

[Aryanos]

Are there significant changes to the database with this upgrade and how the worklfows work from SP1 to SP2 in terms of components, design or variable names? We're about to roll SD7.1 SP1 out and this is very concerning to me and we can't really delay it see how SP2 works. There really needs to be a better way to do this as this simply isn't acceptable at all.

[Migration User]

Poking around and preparing for what I thought was going to be an upgrade and making the modifications that I had on 7.1 I have noticed a lot of differences in the core workflows. Some are small changes and others will take some time to reverse engineer if we have to (I don't think we will but you never know). As for the database, I really don't know what differences there are because I don't really see the need to be in there too often. There must be enough of a change if we're being told that IncidentManagement Processes that previously exist will no longer be able to be worked if an upgrade is done. This does not give me that warm and fuzzy, customer-comes-first, feeling. 

If I were you and you haven't rolled out SD yet, it might be worth considering rolling out SP2 since you will need to build a new server and a new database if you need to go to it or possibly a future version.

[Aryanos]

Have you noticed if things are still hardcoded in the workflows like Support I, Support II? That was one of the fustrating things when we were doing our customizations as it seemed like things were hardcoded everywhere instead of using variables.

[Migration User]

Support I and Support II are still hardcoded in some places. If you have a specific workflow in mind I can look but I have seen them listed individually.

[Migration User]

I has been recently mentioned to me by support (with an on-going case that we have) that it might not be best to migrate to SP2 as of yet. There is mention of another release mid-2012 that will ALSO require a migration rather than an upgrade but as of that release all subsequent releases will be proper upgrades rather than these ridiculous migrations and headaches. Only time will tell, the question remains "How long can I hold my IT department at bay?" 

[toomas]

Since ServiceDesk has configuration settings for group names including Support I and Support II, if you places where these are still hardcoded, please raise it with Support and reference the specific locations.

[toomas]

Product documentation gets automatically published into separate KB articles for each chapter/section. This particular article is for ServiceDesk 7.1 SP1.

[Migration User]

Thank you all for your posts. I fully understand your concerns and frustration regarding the ServiceDesk 7.1 SP2 upgrade path. We have been less than thorough in explaining this in the latest release notes, and are working to quickly update this document to provide appropriate guidance.
To confirm, an in-place upgrade path is not possible for SP2. Customers who wish to upgrade will be required to set up a new server for SP2 and run their existing instance in parallel. A script is available to migrate closed incidents to the SP2 instance, and we are in the process of creating additional scripts to migrate Problem and KB data (http://www.symantec.com/business/support/index?page=content&id=HOWTO61259).  Note that these scripts may need to be adjusted slightly based on any customizations you may have made to these processes.
Because of the effort involved in transitioning to SP2, we are generally only recommending this for customers that require the updated Change Management process, as this was the most substantial new feature introduced in this release.
For customers on ServiceDesk 7.0 MR2 or 7.1 who are considering upgrading to address performance issues they may be experiencing, we are offering the following guidance:

1. Customers on ServiceDesk 7.0 MR2 should consider installing the Workflow 7.0 MR4 Pointfix Rollup. Information regarding this rollup is available at http://www.symantec.com/business/support/index?page=content&id=HOWTO60820
2. Customers on ServiceDesk 7.1 should consider installing the Workflow 7.1 SP1 Pointfix Rollup
3. Customers on ServiceDesk 7.1 SP1 should review the fixes available in the 7.1 SP1 Pointfix Rollup to determine whether installing this may address any performance issues they may be experiencing.

As you are aware, providing a simple upgrade path for a customizable service desk product comes with many challenges, and fully addressing these challenges is the top priority for our go-forward strategy. We will be providing more information about this in the coming weeks.

Will Lewis
Sr. Product Manager, ServiceDesk
 

[Aryanos]

We're about to live with SD7.1 SP1 and we started in September engagged with a consultant. It's been about 5 months in preparing for the launch and it's really tough to hear these are the only upgrade options available to us. Ideally I'd we'd like to delay it and start with SD7.1 SP2 so we wouldn't have to worry about future upgrades but we promised the business that it would be in this month so that's not an option.

To tell our IT Director that we now have to setup yet another minimum of two servers (test and production) with the high hardware specs needed for the production one, work in two different systems and maybe engage yet again with the consultant to do is asking a lot from your customers. Sorry to sound so negative but this was not something we had planned for or knew was coming from your team.

[Migration User]

Will, you are recommending this SP2 for customers that require the updated Change Management process, but not to users who don't use Change Management. What happens when the next upgrade comes out? If users stay on Sp1 are they going to have to take sp2 to get to the next upgrade or are they going to have to do the same thing and rebuild everything from scratch?

My IT management team is already not happy about ServiceDesk. Symantec is not making this user friendly for their customers.

[Migration User]

There's one major flaw in this idea of where customers should be at and what version they should be running. If we have upgraded the rest of CMS to SP2 in order to deal with issues there as well as upgrading Asset Management to SP2, we no longer have access to the older versions of SD. If I am at 7.1, where can I get SP1 now?

Also, do you know how you will be providing the information that you are talking about? Will we just have to keep scouring the KB, will it be a direct email to customers who license SD or should we look for it here on the forums (or all of the above)?

[Migration User]

I see potential in this product, but the ability to deploy, manage, maintain and/or modify this extremely complex system has also left our IT management team (as well as the helpdesk team) less than happy with Servicedesk. Not to mention the steep hardware req's to run it at a minumum. Now, finding out about the "upgrade" hoops we need to jump through...it is killing us.

[MRenfrow]

We were in the same boat as you.  Starting planning in October with a January implmentation  Went live last week with SP1 and have had a few issues(of course).  Some of the issues we are having are addressed in SP2 but told managment about upgrade issues(new server, new install) and they decided we will live with current issues.

[Migration User]

Thank you for your replies.  Our next version of ServiceDesk will address the current upgrade path challenges by providing a much more robust and comprehensive Rules Engine interface.  If you have seen the new Change Management process, you are aware that there are a number of rule sets that covers the various states within the Change process. This same model will be applied to Incident and Problem and a number of new rule sets will be added.  As an example, you will be able to create a rule that sends an email notification to the owner of an incident when the submitter adds a comment.  In addition, we will be incorporating Boolean logic to provide additional flexibility in defining how these rules behave. 

We believe that our continued focus on developing the Rules Engine is key to enabling a much simpler upgrade path, and our plan is to support an in-place upgrade from the next release forward.  At this point, we are expecting a calendar Q3 release.
Please do not hesitate to contact me directly if you have additional questions.

Will Lewis
Sr. Product Manager, ServiceDesk
[e-mail]
281-712-2506

[Aryanos]

That's good news bout the the Rules Engine. We actually had to build our own Routing Rules engine because the one in Service Desk just wasn't robust enough. We needed the ability to auto-assign and auto-classify new tickets submitted by email by looking at key words in the subject, body, and the from email field similar to how Altiris Helpdesk was able to do.

Is your team going to be demoing new features of Service Desk at the upcoming Vision conference as well.

[Migration User]

Yes, we are planning to demo some of this new functionality at Vision in Las Vegas.

[Migration User]

I have used Helpdesk since version 5.5, granted the last version 6.0 sp whatever it ended at didn’t have everything we wanted but it did the job. Then they came out with Service Desk 7.0 and that was a huge bomb. I even sat down with some employees from Symantec and told them things that we had to have to make the change smooth. I feel like nothing was taken in to account, especially after SD 7.1 came out. There were improvement but it was like no one looked at the forums for things we really needed and wanted in SP2. I have talked with different consultants telling them what we would like to do with the product and they say, yes we have heard or done that for other customers. With the time and money that goes into building the test and production systems I can’t afford to pay consultants to come in and rewrite things it to the system. Then turn around and find out I can’t upgrade and have to start all over. I would stay with Helpdesk 6.0 but now there’s no support for that anymore. I'm with jpellet2 and hamsalad00 on being a champion for this product. When my project manager comes to me and tells me there got to be a better product out there, I can’t argue with him anymore.

Now I have to keep my fingers crossed that the routing rules get put in for Q3 which will more than likely be early Q4. I’m really disappointed.

[Aryanos]

For those companies that don't have a dedicated Workflow Developer I can see how fustrating it must be to use the product. Fortunately for our company I am one but if we were to have a consultant do the customizations that we wanted it would have costed us a lot more in consulting fees. Service Desk isn't generic enough to fit how your company works so it requires a lot of customization unless you change the way you run your department to the way they have it set.

[sdmayhew]

The problem here is that we are only mentioning Service Desk 7.1 SP2. If anyone has Barcode - which was 2 YEARS behind. the offical answer is to upgrade to SP2 which requires a upgrade to the NS. Plus all the changes to the inventory module.

So if you are a asset manager customer you will need to upgrade to SP2. Which means I get to tell my customer that he needs to give me 2-3 weeks to do another upgrade! Plus rewrite my 170 page run book. Then retrain all end users on the new process.

They were not happy when I presented  this project to them and said it was because of the vendor! Especially as I already did a SP1 major upgrade in 4th quarter 

Even as a product champion this is a tough pill to swallow. 

[Migration User]

I think Symantec should deal with the consulting costs associated with "Upgrading to SP2".  This product has really gone downhill fast. Between the lack of customer support in the past and now this, it is a wonder how anyone that recommended Altiris has a job.  How much egg on the face does Symantec expect us to take before we all throw in the towel on this line of product?  Frustration is running wild.

[dsmith1954]

Someone needs to take the old Altiris products and create a new Altiris company, or spin off the old Altiris so they can get back to listening and responding to the customer. Symantec has done nothing but mess up their entire product line. It wasn't perfect, but it was better than what Symantec has given us.

We were going to migrate from HelpDesk 6.x to ServiceDesk 7.1 SP1 soon, but after reading all of this, I don't think I can present this to management. This just sux - big time!

Seriously. What are you thinking Symantec? The old HelpDesk may not have all the features of ServiceDesk, but it doesn't have all the upgrade headaches either. It is way more robust that ServiceDesk, and it is on a 5 year old server. Our new ServiceDesk is on an extremely fast (I/O fast) server, as is the SQL database, but performance just doesn't match the HelpDesk.

Who has time to learn Workflow, or money to hire consultants or dedicated Workflow designers? HelpDesk is so easy. We had consultants install and configure it when economic times were good, but it was easy to learn how to do things.

Oh for the good ole days when vendors used to care, and actually provided good customer service...

Altiris where are you??? Bring it back!!!

[dsmith1954]

One other thing - my SIM hasn't even offered SP2 for anything yet - CMS, AMS, ServiceDesk. SIM sux, too. With Altiris 6.x, I could just browse out to the website and download what I needed. Now what? Symantec will probably say I have to uninstall/re-install my SMP.

[rdvanorman]

I must say that I too am disappointed/frustrated with this process.  We just paid a consulting company to come in and help us get this installed/configured and we're about to start using it then this comes out.  This isn't a "Service Pack" this is a complete reinstall and configuration.  We're not a large company with a dedicated admin just for Symantec products, I wear many hats as I'm sure most of us do.  What's the thinking here?  We've been with ALTIRIS since 2002 and I really have to ask myself and my boss if this is really the best solution for us now.  

[Aryanos]

Funny thing is when we went to Service Desk I'm always asked if we can add features to it so that it's like Altiris Helpdesk 6.5. 

[toomas]

Altiris™ Client Management Suite 7.1 SP2 from Symantec™ Release Notes (http://www.symantec.com/docs/DOC4723)

General installation and upgrade information (Page 10)

To perform an upgrade from version 7.1 or later, in the Symantec Installation Manager click Install New Products, and then choose to install this product. Do not use the Install Product Updates page to upgrade.

 

Also, definitely, take a look at this as well:

Upgrading to ITMS 7.1 SP2 - Best Practices (http://www.symantec.com/docs/TECH177513)

[dsmith1954]

Really? Symantec is really messing up on this one.

Having to use this silly SIM is bad enough, but what's the point in having a "View and Install Updates" option if you're not going to use it? And, how/why is an SP2 a "new" product? I know, it restructures the database. If it requires a new server(s) installation, is not listed under "View and Install Updates", then it isn't an SP2. It's a v8.

HelpDesk v6.5 - I think we're here to stay. Supported or not, it is still the best version available. Much faster response times, and much faster development times. It may not have Java, SilverLight, and Flash all rolled into one product, but at least it works, and works well.