ServiceDesk

Just sharing some information for early adopters - when upgrading from SD 7.5 to SD 7.5 MP1 I recieved a big red message "The Administrator username format is incorrect, email format is required (Example:admin@symantec.com).".  This occured on the page where you define the admin account for workflow before SD is installed.

It looks like the new installer now checks for this common issue which is great.

Except in my case this was an upgrade of a functioning SD 7.5 install, the installer had pre-populated the fields, had greyed the admin account name field out AND the account was in the format specified.  I couldn't change the account (nor would I want to) or move past this page with this error.

My work-around was to grab the workflow installer off my SMP server (default C:\Program Files\Altiris\ServiceDesk\Web\Agent) and run this seperately.  Next next next and the install completed fine on my lab server.

With Workflow upgraded I skipped to the ServiceDesk install component in the main installer and carried on.

Process Manager seems to be working and I can see a few changes (like Select Group when Delegating an Implementation Task in CM).

Just to clarify - the admin account already used was in the e-mail type format.  In my case the top level domain was .local (eg. something@anotherthing.local).

I think the decision was made in this release to just show what the admin user was in PM, and not let SD do any kind of interaction with it. It makes sense, being that Workflow is responsible for the configuration of PM and all.

Rerunning the WF installer would correct the issue. But you have a good point: we shouldn't really validate the format on the SD end, we should just show it. WF should be resonsible for the validation (which we do have now... checking for email type format)

EDIT: Disregard comments about the admin name needing to be greyed out... this is what happens when you've only run the new SD installer a handful of times. Didn't know it actually collected the data for a WF install (or I forgot).

Lark,

Thanks for providing this information and bringing it to our attention. We are currently evaluating the issue on our end. Once that is complete we'll update this post with how we are addressing the issue.

Glad to hear there is a simple work around to address this issue, so you are able to proceed with the install.

Sorry I probably should have logged a support case - it just seemed like a glitch on my lab setup as a customer's install didn't have the same issue.  They of course have a different top level domain that would be suitable for internet based dns resolution - unlike my lab (which is by the way quite intentional).

I tested on a full uninstall and re-install in my lab with the same result so this looks like it affects new installs too.  Changing the top level domain to something@anotherthing.com worked ok and let me past that stage of the install. I couldn't continue with though as thats not the domain I use.

As with an upgrade installing the new Workflow version first was an easy enough work-around.  Compared to the night-mare old 7.1 install for Workflow when SQL is off-box this installer is actually really good.