Set logonHours Attribute of Users

PowerShell script to assign the hours when users are allowed to logon to the domain

 
 
 
 
 
4.8 Star
(4)
1,914 times
Add to favorites
Active Directory
2/6/2017
E-mail Twitter del.icio.us Digg Facebook
Sign in to ask a question


  • UTC users out of luck?
    2 Posts | Last post February 06, 2017
    • When table-testing the code, it seems that in the case where $Bias -eq 0, the variable $Hours gets assigned an expression containing uninitialized values - "$Str2$Str1". Moreover, it seems that the bias of PST timezone (-8 ?) should also be accounted for. When I do, I get Mon-Fri 7 am-8 pm test user out just right.
    • I modified the script to correctly handle cases where the local time zone bias is 0. It was an oversight on my part, and a very minor update. Thanks for pointing this out.
      The bias for PST should be 8. I know the bias for CST is 6.
  • Is this logon script works to set half hours for allowed users
    2 Posts | Last post December 18, 2013
    • we are in problem, we want to set half hours times for our users or clients to logon but we didn't found any solution till yet, now if this script works for us then please help with us, and give some tips how to configure the AD or change some parts of the current script.
      Thanks
    • There is no solution to support half hours. The logonHours attribute in Active Directory is a array where each bit represents an hour, so there is no way to represent half hour increments. The same is true in the ADUC GUI interface, where you can only allow logons in whole hour increments. Sorry.
  • Bias is too big?!
    4 Posts | Last post April 30, 2013
    • Hi Mr. Müller
      
      Thanks for your script for setting logon hours. But it doesn't work in my environment (2008 R2 DC). Because the bias variable has 71582787 and the lenght of hours is only 168... it gives me an error because lenght can't be smaller than 0... 168 - 71582787 is of course below zero... what is wrong with my bias entry in the registry? (its: ffffffc4 in hex or 4294967236 in decimal) and i don't get the problem... what should be the bias value? would be awesome if we can fix this, seems that I'm too stupid ;-)
      
      Regards
      Stephan
    • btw: my timezone is W. Europe Standard Time / Central European Summer Time (CEST) +0200 UTC 
    • Strange this hasn't come up before. I've been using similar code for perhaps a decade and this never was brought up. Clearly, your large value represents a negative number. The only way to represent negative integers in 32-bit storage location is to add 2^32 (4,294,967,236) to the number. You value is -60 minutes, or -one hour. But when subtracted from 168 this results in 169, which probably should be 1. I need to check this out and figure out how to handle it. However, your time zone suggest the bias should be 2 hours, not 1. Does a time zone bias of 1 hour make sense for you now?
    • I've updated the script to properly handle negative local time zone bias values in the local registry. Note that the proper bias value does not change with daylight savings time changes, but is constant throughout the year. Let me know if this does not work properly in your time zone.
  • worked perfectly
    1 Posts | Last post September 19, 2012
    • the method [math]::round(d,decimals,[midpointrounding]::awayfromzero) syntax worked perfectly, just as expected for the time zone difference.
      
      Thanks!
  • live in strange time zone offset
    2 Posts | Last post September 18, 2012
    • Mr. Mueller,
      
      Firstly--thanks for posting this script; it's a great model from which to learn.
      
      I happen to be living in Afghanistan currently and we have a timezone offset of UTC +4:30.  Using the script and the banker's rounding method of the round function prescribed for use, if the local logon hours are bound by the top of the hour, the way they are stored in AD under UTC times and the substring adjusts for the difference, this will effectively not allow the users to login for 30 minutes when they should be able.  This is a limitation of the rounding methods available in powershell.
      
      From what I've read, powershell is supposed to be an amalgamation of .NET, C#, and BASH.  However, full functionality is not integrated from .NET methods that allow you to control the way the math::round function works with midpoint rounding, as far as I can tell.  Do you know of any way to control the midpointrounding so it uses an "awayfromzero" method instead of "toeven"?
      
      I would greatly appreciate it and I'm sorry I'm late for the party, I know this is a relatively old post, but I just recently started studying for MCITP and I'm trying to teach myself powershell to accomplish all tasks for the exercises in the study guide.
      
      Very Respectfully,
      Mario
    • Thank you for pointing this out. There are several times zones where the bias is not a whole number of hours. There is even one (Nepal) where the bias is 5:45. If you confirm that the proper correction factor for logonHours is 5 hours when the biase is 270 minutes, then the solution follows. Replace this line in the code:
      
      $Bias = [Math]::Round((Get-ItemProperty `
          -Path HKLM:\System\CurrentControlSet\Control\TimeZoneInformation).Bias/60)
      
      with this:
      
      $Bias = [Math]::Round((Get-ItemProperty `
          -Path HKLM:\System\CurrentControlSet\Control\TimeZoneInformation).Bias/60, 0, [MidpointRounding]::AwayFromZero)
      
      Another workaround would be to add 15 minutes to the bias before dividing by 60, but using the MidpointRounding parameter seems better. I will modify the code today, but let me know if this does not fix your problem.