ServiceDesk

 View Only
  • 1.  AD import sets wrong time zone for users, they cannot log in

    Posted Apr 06, 2016 11:36 AM

    Service Desk 8.0

    Active Directory synch profile imports users as scheduled, and AD authentication is enabled. However, users are all associated with the wrong time zone.

    They cannot log in unless each user is selected, Manage User, Process Manager Settings, and correct time zone is selected.

    Once each user is set to the correct time zone, they can log into the Process Manager portal.

    I cannot find where to change this default setting (UTC-12:00 International Date Line West) so that users are imported and associated with the correct time zone (UTC-05:00 Eastern Time). I do not want to individually correct hundreds of users to allow them to log in and create Incident tickets.



  • 2.  RE: AD import sets wrong time zone for users, they cannot log in

    Posted Apr 06, 2016 12:51 PM

    I have seen exactly the same issue.

    I know you could also try to modify this in the processmanager database as well. With the right SQL command I think you could do this in bulk as a workaround, but it seems its definitely a small bug here, so a support rep should be contacted.

    The values are in the table dbo.User and the columns are 'DynamicallyTimeZone' and 'SelectTimeZone'.

     

    kr,

    Davy



  • 3.  RE: AD import sets wrong time zone for users, they cannot log in

    Posted Apr 07, 2016 03:38 AM

    ServiceDesk sets a wrong timezone for user while the time is correct
    https://support.symantec.com/en_US/article.TECH166190.html

    Case Age value for users in timezone other that ServiceDesk SQL Server is incorrectly calculated
    https://support.symantec.com/en_US/article.TECH209360.html



  • 4.  RE: AD import sets wrong time zone for users, they cannot log in
    Best Answer

    Broadcom Employee
    Posted May 05, 2016 06:39 AM

    This is going to be a bit long but please bear with me.

    Users' timezones, their detection and related functions have been somewhat of a sticking point throughout SD/WF 7.x. A lot of this is figured out, fixed or improved by now. Unfortunately, there are a couple issues that somehow found their way into SD/WF 8.0 release that made these problems very visible and break Portal functionality.

    Alex's links to KB are good to know but not exactly relevant to what jmillner is seeing. Let me elaborate a little on these two here:

    • TECH166190: Timezone detection works on offset, not the actual timezone. This is more of an annoyance than a functional problem in later 7.5 versions, 7.6 or 8.0. It does not look nice in User Account page but otherwise the calculations will be correct. Also, note that if timezone is dynamically selected for user (which it is by default) daylight savings time changes will get accounted for at user logon.
    • TECH209360: Case Age problem should be resolved in later versions of 7.5, 7.6 and 8.0. One of the bigger changes in WF/SD 8.0  is that all the times in database are saved in UTC time. This makes working with different timezones much more reliable.

    Back to the question in first post - this is caused by combination of two different problems in 8.0 release:

    • Dynamically detecting timezone (i.e. setting timezone for a user at logon) does not work when logging on with pass-through authentication. Incidentally, this is exactly how most users are logging into the Portal.
    • There is a problem that popped up at one point in 7.6 as well that web parts with a report do not handle empty timezone values properly.

    When user's are imported from AD, timezone is not imported. It is supposed to be dynamically set when user logs on. Due to the first point, this does not happen. The 'UTC-12:00 International Date Line West' timezone you see in the Portal is in most cases not the data in the database. It is Portal's interpretation of NULL value. When a new user (that has NULL as timezone) logs into the portal with passthrough, timezone will still be NULL. In most cases, users have Home or Technician Dashboard as home page in the portal, both having a report web part. Here is where the second problem comes in.

    Note that when logging in manually with user name or email address and password, you will not see this problem. The simple reason is that in that case timezone gets set at logon.

    The best way to fix this is to contact Support and ask for WF 8.0 Rollup (8.0.3000.32 or newer):
    INFO3609: Workflow 8.0 Point Fix Roll-up

    The issue with report web parts throwing an exception is fixed. Dynamic timezone detection on passthrough login is improved - it works and nothing breaks but the functionality is not yet 100%, we are working on the remaining problems with that.

    Alternatively, the timezone values for users are saved in User table, SelectTimeZone field. These could be manually set to the desired timezone in the database, with a query like this:

    UPDATE [user]
    SET SelectTimeZone = 'Eastern Standard Time'
    WHERE SelectTimeZone IS NULL

    The problem with this is that newly imported users will still have it at NULL and the same query would have to be repeated. Also, I would generally discourage changing things in database directly. In this case Rollup is a much better option.



  • 5.  RE: AD import sets wrong time zone for users, they cannot log in

    Posted May 05, 2016 09:45 AM

    I very much appreciate the input from all of you, now have a much better understanding of the cause of the problem. I did end up calling Support, and installed the HF, 8.0.3000.32. This enables users to log in without having to manually make changes in the database, or worse, manually change all of the users one by one. Although when a user sends a comment via an email response, the time appears to be incorrect, this is a minor issue compared to no one being able to log into the console.

    Thank You all again.

     

     



  • 6.  RE: AD import sets wrong time zone for users, they cannot log in

    Posted May 05, 2016 09:45 AM

    I could find a KB for the exact error and TECH209360 had the same SQL as below, so thought it might be worth referencing.

    We'd been given this to check

    -- Let us see what we have
    select dynamicallytimezone, primaryemail from [user]
    where selecttimezone is null
    and isactivedirectoryuser = 1

    Then this to change

    -- Flip the Dynamic Time Zone bit for AD users that do not have a static TZ setting.
    update [user] set dynamicallytimezone = 1
    from [user]
    where selecttimezone is null
    and isactivedirectoryuser = 1

    Case: 10261236



  • 7.  RE: AD import sets wrong time zone for users, they cannot log in

    Posted May 05, 2016 09:51 AM

    One more issue comment; the documentation for the HF says to run the executable to install, but this does not work. We moved and renamed that exe to what the original Service Desk installer referenced, and then upgraded using the Service Desk installation file and app, not the HF executable alone. Also had to change app pools in IIS to use .NET 4 if they were using .NET 2.



  • 8.  RE: AD import sets wrong time zone for users, they cannot log in

    Posted May 05, 2016 09:57 AM

    The final hurdle for full implementation remains being able to monitor multiple mailboxes and route to queues or categories based on the inbox.

    There is a Workflow solution out there for 7.5 SP1, but the solution has to be for 8.0.

    That will no doubt be a separate discussion.

    Thanks for your help with the issue discussed here.