Symposium Daylight Savings not working

[dudecrush]

Hi there. I'm using Symposium CC Express V 4.0, attached to a CP 201i(v4) and a Option 61. The call center is still on standard time, not daylight, so the calls don't route to agents until an hour into their shift.

What I don't understand is why this is happening. The time on the Symposium server, Call Pilot and PBX are all within a minute of one another - and are correct for Daylight Savings. My understanding is that the CP and Sympsoium get their time from the PBX. If this is the case, why aren't calls routing like they should?

Any insight into this would be great.

 

[bigindian65]

yes, they get their time from the elan. your center is on Standard time, and your telco is on DST, you don't see that as why it would be an hour off?

Mato' Was'aka

 

[Tman45]

I read into your post differently - as you saying that the Call Center script is not routing calls for the first hour of your shift. So I would double-check your scripts too (to make sure they have the correct hours for Open Hours and Closed Hours) - was there anyone working on the PBX prior to you - or someone else that has access to modify the scripting? Some Call Center people here do have access to change scripting. I agree that it doesn't make sense that your Symposium, Call Pilot, and PBX all show the proper time for DST but your Call Center isn't getting calls for the first hour. If it isn't a weird thing in scripting I would set the Symposium time manually on the server (if there even is one - not sure with CCExpress 4) and possibly even reboot it if it still won't work and everything looks correct.

 

[dudecrush]

Let me clarify what I was trying to say - the call center seems to "think" it's on standard time, even though the time on the Symposium PC, Call Pilot and PBX are set correctly.

We haven't made any modifications to the scripts. However, I was told that since Symposium is timed to the PBX and not to Windows time, the problem may be that the daylight savings flag in Windows is checked...when it should be unchecked. Apparently, these settings can collide. I'm not sure if I agree with that conclusion, but I'll try it for now.

 

[yyrkroon]

SECC DST setting should be unchecked in Windows and receiveds all update from the PBX - make sure Window Time Service is disabled.

CP DST setting should be checked in Windows and Windows Time Service should be disabled.

 

[dj4020]

What release of software are you using on the PBX. If you are using a NTP server to update PBX time then you have to make sure the offset is set correct. There are also two peps that need to be on PBX one is for correctly setting the offset when daylight savings goes forward (Spring)the other for when it falls back (Fall) The reason is when they changed the daylight savings dates the fixes only reflect on time display the offset doesn't change correctly because of hardcoded date in the offsets. At least that was what I was told when we resolved this issue last year. . .

 

[dudecrush]

dj4020 - It's version 2921, release 3 on the PBX. We aren't using any NTP server. I'm not sure what PEP releases you are referring to, but I am able to configure the Forward Time and Backward time dates on the PBX.

 

[Tman45]

OH RIGHT dj4020 - I forgot we did have to put some scripts on our older boxes that had this DST offset issue. YES, dudecrush you have to be sure your windows DST is unchecked because it will try to set the Symposium time back another hour when your PBX time already adjusted for the hour - but you would think when you go to server desktop screen for Symposium that you would see it is an hour behind ... weird.

So, did you try to reboot Symposium yet?? Could be that Windows just needs a swift quick in the pants to either show you the time is not set right or something else is messed up

If all else is really good with the system times I still say it is something with scripting. Even the tiniest variable can make your calls route an hour late

 

[dudecrush]

Tman45 - Yes - we rebooted Symposium, but that hasn't fixed the problem. I 'd like to know if I changed the time on my call routing if that would take effect right away, or I would have run a database reconfiguration for it to take effect?

 

[Tman45]

That is a good question - I don't know with CCE4 but with CC6 it seems to work on the fly (without a database reconfig). It would be nice to get to the bottom of the time problem first, but it seems that its more important for the Call Center to start on time

 

[dj4020]

As far as changing the time in your call routing it would be that any call after the script is activated will follow the changes you made in your scripts calls already receiving treatment from the script prior to the script activation will get the original script. So in other words it would be immediate, except for calls already receiving treatment.

 

[dj4020]

Oh I forgot once the old DST rolls around the server will go ahead one hour. Again this due to microsoft just putting in a display of time correction not the offset. So watch for that as well.

 

[dudecrush]

Tman45 / dj4020: I still had the problem this morning, so I came up with a stupid work-around: I remembered that the Call Pilot application scripts had a day-control setting on them. I set them back an hour and - violia! - they began taking calls. Is perhaps the call pilot our culprit?

Of course, I'm now waiting for the ax to fall, because you know that at some point in time DST is going to kick in and then everything will want to start an hour early.

 

[dj4020]

Are you front ending calls with CallPilot then going to CC. If you are then yes that would be your problem. Or if you are answering with CC then sending to CallPliot for a menu perhaps.

 

[dudecrush]

dj4020 - Yes, we are front-ending the calls with Call Pilot before heading to the CC. What I don't understand is why the CP's hours don't sync up with the PBX. Our CP is Server 2003 Appliance Edition, and the Windows time is set correctly; and like I said earlier, the PBX time is set correctly.

 

[Tman45]

Ok I would reboot your 'appliance edition' Windows CallPilot Did you do that yet? I have never heard of appliance edition - that must be like millenium edition that had LOADS of problems Could be that you need those DST scripts loaded on that box

And back to vvrkoon's post - is this setup correctly?
CP DST setting should be checked in Windows and Windows Time Service should be disabled. Maybe your windows time service is running?

 

[dudecrush]

Tman45- No, I haven't rebooted the server yet. I need to wait until th wee hours to do that. The CP has all the latest PEP's, so I don't understand why DST didn't work. It worked fine last year.

CP DST is set up correctly. The Windows DST has been unchecked, and the TIme Service has been disabled.

I did find another post on the Call Pilot forums, and one guy just suggested restarting the CP's time service instead of a full reboot.

 

[Tman45]

Yeah you can try messing with the time services. Do you happen to know if there were any DST scripts applied to this Windows box? Anyway, just seems like a Windows error or something going on with NTP that is causing this issue. Your NTP has the correct time, right??
Wish we could help more - wonder what to do next if a reboot doens't resolve it - hmmmmmm

 

[yyrkroon]

@dudecrush:
you wrote: CP DST is set up correctly. The Windows DST has been unchecked, and the TIme Service has been disabled


Windows DST needs to be checked.

If your CP time is off, make sure DST is check, window time service is disabled, rerun config wizard and reboot. Your CP should be fine after that.