As most of you are on holiday, I wanted to share some insights on home computersJ.
When you have more than one child like I do you always have competition for using the home computer. Competition is good as long as you have the necessary rules to facilitate smooth operation. Up until now, I had only one local account on our house computer running Windows 7 and the account. The user profile was locked down and only allowed for specific applications (read games) to run. However it had one major flaw. Any one child sitting in front of the computer can monopolize the time until a parent intervenes. This causes the all children except one to complain about how long the one at the computer is playing. So solution to that problem would need the following attributes:
· The computer should keep track of who is allowed to logon and when and for what duration.
· It should provide detailed logs around who is disallowed from logging on and how much time is remaining for a particular user.
· It should provide global settings that can be set from a central location.
· It should auto-install and create necessary information stores if necessary.
· It should discourage the usage for a long time so that others can use the computer but allow it after a certain time interval so that it gives credit for persistence.
The computer is in workgroup so using domain based controls is not an option. You can not use a script in start menu startup as it would be too easy to detect. The best approach is to use run registry key for local users. However I used parental control feature of Windows 7 and regedit was not available inside the restricted user account. The workaround is to logon to an administrative account and load restricted users registry hive (ntuser.dat) and set the run registry key. I created a powershell script that would implement the above attributes. Do not forget that run will issue the command before explorer is started so environment variables will not be there and you would need the full path. Below is the line I exported from regedit. I purposefully did not provide full file as loading hive will give different names for different users:
"LogoffTimer"="C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\Powershell.exe -windowstyle hidden c:\\windows\\logoffTimer.ps1"
This line will run the powershell script logoffTimer.ps1 without showing a window to the user. The script starts when the user logs on and first checks if registry values are present. These are used for storing information around time used on last session, logon count, last logon time and time used for the day. It will create if values are not present. This way if you need to add another variable to the script you do not need to reset the registry.
if (Test-RegistryValue "hkcu:\software\erenturk\LogoffTimer","UsedDailyMinutes" -eq $False)
{
new-itemProperty -path hkcu:\software\erenturk\logoffTimer -name "UsedDailyMinutes" -value $UsedDailyMinutes
}
else
$UsedDailyMinutes=(Get-itemProperty -path hkcu:\software\erenturk\LogoffTimer -name "UsedDailyMinutes").UsedDailyMinutes
Next we check if a day has passed since last logon, if it did we reset counters in registry for a new day otherwise we check if daily quota is reached and log off if necessary.
$lastLogonDelta=New-TimeSpan -start $LastLogon -end $now
$lastLogonDeltaDesc=GetTimeSpanDescription($lastLogonDelta)
if ($LastLogon.day -eq $now.day)
add-content $logfile "$username has logged on for $UsedDailyMinutes minutes Today, $DailyLogonCount times and last logged $lastLogonDeltaDesc ago"
add-content $logfile "$username has used $usedSessionMinutes minutes session time on last logon"
$DailyLogonCount=$DailyLogonCount+1
set-itemProperty -path hkcu:\software\erenturk\logoffTimer -name "DailyLogonCount" -value $DailyLogonCount
if ($LoggingLevel -gt 2) {add-content $LogFile "INFO: Day has passed since logon, reseting counters"}
set-itemProperty -path hkcu:\software\erenturk\logoffTimer -name "UsedDailyMinutes" -value $UsedDailyMinutes
set-itemProperty -path hkcu:\software\erenturk\logoffTimer -name "UsedSessionMinutes" -value $UsedSessionMinutes
add-content $logfile "$username is logging first time today,last logged on $lastLogonDeltaDesc ago"
If the user is logging on for a second time, we check if the session time is finished. This is implemented so that if user logs of before allowed time, he/she can logon immediately afterwards. This is generally needed for accidental logoffs. If their session time has finished, script will check for last logon and will not log you on before a certain time passes. This gives chance to other users to use the computers before the first one is allowed again.
If user is finally allowed to log on, we create a loop that will awake every minute to see if time is finished and write the time left to log file, when it does writes the used minutes and logs off the user.
$EndTime=$now.addMinutes($SessionTimeLeft)
$TimeSpan=new-timespan $now $EndTime
while ($timeSpan -gt 0)
$timeSpan = new-timespan $(get-date) $endTime
sleep -Seconds 60
$UsedDailyMinutes=$UsedDailyMinutes+1
$usedSessionMinutes=$UsedSessionMinutes+1
$Remaining=GetTimeSpanDescription($timeSpan)
add-content $logfile "$Remaining remaining..."
add-content $logfile "Session time allowance is reached, user will be logged off"
logoff
After I implemented the script and made the necessary rules, I was amazed to see how fast it was received by the children. You can find the script attached to the post.
If you have large distributed environments, you will have connected branches to your headquarters. More than a decade ago, these links had small bandwidth (around 64kbps) or even used X.25 like some of my customers. Generally links were unreliable and had a tendency to malfunction from time to time. Using backup lines were either prohibitively expensive or alternative technologies were in their infancy to be used reliably. Back then you needed servers in your branches and use caching on those servers so that you can resume your work in case your link goes down. Some of my customers had (and some still have) teams monitoring all the links (some over 1000 locations) and working with the ISP to resume service on some of them. My customers used to have large number of sites in Active Directory and file servers running on branch servers. You also needed backup software and tape drives on those machines to do local backup. When you work in these environments for some time you tend to attain a habit of keeping whatever you have and this blurs your vision of connectedness.
During the last decade, link speeds and reliability have gone up considerably. You can use 3G wireless backup lines for your primary lines and link speeds have reached 1-5 Mbps for most of the places. Your mileage may vary but the point is link speeds have gone up at least 20 times (my home Internet connection speed has increased 40x times in this period) and you can attain high available lines with much less effort combining different technologies. Not only can you use higher bandwidth to connect your branches but you can have a different topology as well. Think of this as a slider where each point will enable different functionality as you increased your connected bandwidth. If you slightly increase your line bandwidth you can start taking backups from central location during nights or you can remove branch servers from your smaller branches. I did an analysis several years ago for one of my customers around what the optimal number of PC’s in branches need be to make it feasible to put branch servers. I included operational link costs, initial cost of the servers and an estimated maintenance cost for servers and came up with a magical number of 14. If branch had less than 14 PC’s customer placed no branch servers but serviced PC’s from central site instead. Of course your magical number may vary on your own conditions however the point is, the more you feel comfortable with the links the fewer servers you will need in branches.
There are organizations that have created their topology over a decade ago and have not changed it since. Some still fear of unreliable links and keep Exchange servers in their branches. (One specific customer of mine has over 600 Exchange servers) Exchange Server is designed to be placed in central sites for the last two versions at least and it’s getting harder to deploy it in branches with each new version. Some customers refuse to use read only domain controllers (RODC) on the basis of the extra load it brings to the network. It may not be feasible to remove every branch server in your environment, however if you still have branch servers in all of your branches it is time to reconsider your server placement strategy.
There is no point in trying to upgrade your software if you do not adapt yourself to the new perception of connectedness. Some of my customers are already using VPN over Internet between their central sites and branches and have reduced their branch servers with a goal of reaching down to a dozen locations that will have servers. Looking into the near future, we will be using IPSec VPN’s over IPv6 Internet for all of our client machines without even knowing which of branch servers is closest to you, so start getting ready now.