All is not well with the King

My wife and a couple friends frequent a local Burger King 2-3 times a month, and let the kids play in the play area.  On one such trip back in October my wife was overcharged $10 so instead of a $15 charge she was charged $25. Being an accountant the wife noticed the discrepancy fairly quickly. She also alerted her friends that were with her on that day of the issue, one of them was also charged $5 extra.

So the wife called Burger King and explained the issue. Seeing that her friend got his $5 back she didn’t think it would be an issue, but since she didn’t have her original receipt, store management was less than helpful.

If the customer says you charged them too much, and you know that another customer on the same day was over charged, then it would be advantageous to the business to err on the customer’s side and at least do a little investigation.  Neither of which were done in this case.

Now had this been me,, I would have broke the picket signs and besieged the Burger King. But due to the fact the Burger King in question is the only one with a play area and centrally located for the group, my wife decided to continue to frequent the establishment with the change of only paying with cash.

The cash basis Burger King went on for 2 months without a hitch, but then the mistake was made to use the debt card again toward the end of December. Low and behold an extra $10 was once again tacked on to the bill. Once again store management was unresponsive and it took days  even answer the phone.  Corporate was contacted and the number of the Owner was obtained.

After discussing the issue with the owner, records were faxed over. A couple days later security contacted my wife and explained that they would be investigating the issue.   Now fast forward a  couple weeks,  the security guy calls my wife and explains that they were able to isolate the employee and that employee was fired after admitting to overcharging unknown numbers customers over a 4 month period. They are also looking to press charges against the ex-employee.

Now Burger King still hasn’t refunded our $20 or provided any concessions even after it was found to be fraud on their part.  Which leads me back to question why wouldn’t management, owner, security or anybody refund the overcharge as soon as it looks plausible that the customer has a valid complaint?  Heck, they even asked my wife to be come down to the court house and file charges against the employee, which we promptly declined.  Come on we have already wasted much more than the $20 in the time it took to even contact them. Had this issue been taken care of and investigated in October countless customer would not had their hard earned money stolen from them when all they wanted was a Whopper!

The sad part here is this employee was overcharging 100s of customers over a 4 month period and no one caught on.  I know we couldn’t have been the only ones who noticed the incorrect charges, and attempted to contact management. How many customers just gave up? I mean what truly is $5-$10. Heck, the first time we ended up letting it slide after not getting anywhere with management.

Moral of the story: If someone contacts you and says they have a problem they probably do, or they wouldn’t waste their time. So take each inquiry seriously, and don’t ignore your customers or you soon will have no customers to ignore.  

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

A Site Link to Faster Logins

While troubleshooting excessive client login times, we identified an issue where the clients in one site would authenticate with DCs on the other side of the country.  

In our case a few of our sites are very well connected to our core site via high speed low latency links, so there are not any local DCs at site that users report slow logins.   

Initial test were inconclusive as a well connected DC was selected by the client, but we got lucky and one of our test system started experiencing the slow login issue.  After login set logonserver was run from the command line and a DC in the remote location with > 115ms latency was selected by this particular client PC.  At this point we were pretty sure the issue was in the AD site configuration, but did a couple more tests to confirm the suspicion.

We then repeatedly ran the following command multiple times to confirm our suspisions:

nltest /dsgetdc:domainname /force

The nltest command with the dsgetdc uses the same API the client does to select a DC.  In our case after multiple runs of the command DCs on the other side of the country were returned.

After notifying the directory services team of the issue it was determined that at the direction of an AD Consultant the site links between the core site and remote site were removed, and since no DCs were present on the site and the clients didn’t have enough information to determine the proper cost of a DC and were randomly selecting any DC in the environment. 

The AD team recreated the site links and the nltest  command  now only returns DCs in the core site.

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Windows 2008 R2 to Support DHCP Failover

 

It appears Microsoft may have dropped DHCP Failover from the Windows 2008 R2 release.  Hopefully they come to their senses, but we’ll see. Feel free to continue reading to see what might have been.

 

About time, Windows 2008 R2 will now support DHCP Failover.

DHCP server services are used to provide automated IP configuration for network endpoints.  Traditionally DHCP lease information is stored in a single database, and this single computer is prone to be a single point of failure. Now you can Cluster the DHCP service, but this still leaves you venerable if the DHCP database gets corrupted.   In the past the only way to elevate this was to use something like a split of the DHCP Scope between 2 servers. This did improve the reliability, but this option didn’t fit in many environments do to the need to have many extra addresses in every subnet.

In Windows Server 2008 R2, the DHCP Failover feature has been included to allieviate outages due to single server failure. The DHCP Failover feature is an implementation of the DHCP Failover protocol.

With DHCP Failover, the servers providing DHCP Server services synchronize DHCP lease information between each other. One computer is designated as the primary DHCP server and the other as the secondary DHCP server.

When computers request IP configuration, the primary DHCP server will respond. In the event that the primary DHCP server is unavailable, the secondary DHCP server will service the request. The big difference here is the secondary server knows about the current leases that the primary server made, and will be able to renew existing leases, and not be forced to give out a new address. This also eases administration and the DHCP scopes do not need to be split between servers.  The DHCP Failover feature will also support two-way syncing to support load-balancing between the primary and secondary DHCP servers.

Now granted there have been some appliances in the market that supported this functionality for the past few years, but this is a great addition to the Window Server feature set. This was something that was lacking from the original Windows 2008 release, but appears to be making it in the R2.

 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,