I have a question about Force NumLock to Behave:

I have done all that was suggested, including changing the value in the registry so that the numlock key will be on at bootup, but it still will not work. I can turn it on manually any time, but even though it comes on initially at bootup, once Windows xp loads, it goes off and stays off until I turn it on myself. Is there anything else I can try?

[Reply or follow-up to this message]

We are having a similiar problem with our new student computers at our middle school. Our CMOS has the NumLock on at Boot. We see that it is on during the initial bootup. However, as soon our our network login screen comes up, the NumLock goes off again. As soon as we login, it comes back on again, we believe this is based on us making the registery changes that were suggested on this site for users with Microsoft Intellipoint devices. We would really like the NumLock to stay on during the network login. Thanks and our students thank you!


On Sunday, June 9, 2002 at 11:22 pm, Ann wrote:
>I have a question about Force
>NumLock to Behave:

>I have done all that was suggested, including changing the value in the registry
>so that the numlock key will be on at bootup, but it still will not work. I can turn
>it on manually any time, but even though it comes on initially at bootup, once Windows
>xp loads, it goes off and stays off until I turn it on myself. Is there anything
>else I can try?
>
>

[Reply or follow-up to this message]

I tried everything listed here without getting my desired result either, but then 
I found yet another registry entry:

HKEY_USERS\.DEFAULT\Control Panel\Keyboard 

There is another instance of InitialKeyboardIndicators here.  When I changed this 
value, NumLock behaved as desired throughout the boot process.

Jeff

[Reply or follow-up to this message]

What worked for me was an article in the Microsoft Knowledge Base, Q314879 - "How to Set the NUM LOCK State at Logon in Windows XP" involves an easily created script file. None of the registry hacks worked for me.


On Sunday, June 9, 2002 at 11:22 pm, Ann wrote:
>I have a question about Force
>NumLock to Behave:

>I have done all that was suggested, including changing the value in the registry
>so that the numlock key will be on at bootup, but it still will not work. I can turn
>it on manually any time, but even though it comes on initially at bootup, once Windows
>xp loads, it goes off and stays off until I turn it on myself. Is there anything
>else I can try?
>
>

[Reply or follow-up to this message]

Like Ann said in her original question, changing the value of InitialKeyboardIndicators under HKEY_USERS\.DEFAULT\Control Panel\Keyboard from 0 to 2 worked for me, but only initially at bootup -- once Windows XP loaded, it would off and stay off until I turn it on myself. So I tried the VB script mentioned in MSKB article Q314879, but that didn't work for me either. Finally I tried Jeff's suggestion of searching for additional registry entry instances of InitialKeyboardIndicators -- I found several instances, and changed the 2 or 3 instances that had a value of 0 to 2, and this finally worked for me. HTH

[Reply or follow-up to this message]

I had the same problem and this fix worked for me also.


On Tuesday, August 6, 2002 at 9:07 am, Valerie wrote:
>Like Ann said in her original question, changing the value of InitialKeyboardIndicators
>under HKEY_USERS\.DEFAULT\Control Panel\Keyboard
>from 0 to 2 worked for me, but only initially at bootup -- once Windows XP loaded,
>it would off and stay off until I turn it on myself. So I tried the VB script mentioned
>in MSKB article Q314879, but that didn't work for me either. Finally I tried Jeff's
>suggestion of searching for additional registry entry instances of InitialKeyboardIndicators
>-- I found several instances, and changed the 2 or 3 instances that had a value of
>0 to 2, and this finally worked for me. HTH

[Reply or follow-up to this message]

The solution for this is simple. After Windows XP has loaded, press the Num Lock key to switch Num Lock on. Then restart the computer. The Num Lock on value will be entered into the registry at shut-down

[Reply or follow-up to this message]

Thanks For Posting Your Fix For Numlocks Mate Saved Me Posting A Q? Your Idea Of Change All Keyboard Setting To 2 Works A1.

[Reply or follow-up to this message]

Thank you so much. This helped me alot. Allthough just for future people looking 
for this.

The complete Instructions 

click: start menu
         all programs
         accessories
         windows explorer
         my computer
         localdiskC:
         windows
         regedit
         HKEY_USERS
         .DEFAULT
         Control Panel
         Keyboard
         InitialKeyboardIndicators
         change the value to 2
         hit ok
         close all windows programs
         reboot your computer
         ... and your done...

Thanks again jeff!!!

Lane Craig






On Friday, June 21, 2002 at 12:37 pm, Jeff wrote:
>I tried everything listed here without getting my desired result either, but then 
>I found yet another registry entry:
>
>HKEY_USERS\.DEFAULT\Control Panel\Keyboard 
>
>There is another instance of InitialKeyboardIndicators here.  When I changed this 
>value, NumLock behaved as desired throughout the boot process.
>
>Jeff

[Reply or follow-up to this message]

Did you EVER find a solution for this - if so, I would really appreciate knowing what it was. Thanks.


On Sunday, June 9, 2002 at 11:22 pm, Ann wrote:
>I have a question about Force
>NumLock to Behave:

>I have done all that was suggested, including changing the value in the registry
>so that the numlock key will be on at bootup, but it still will not work. I can turn
>it on manually any time, but even though it comes on initially at bootup, once Windows
>xp loads, it goes off and stays off until I turn it on myself. Is there anything
>else I can try?
>
>

[Reply or follow-up to this message]

Hi Guys, If I understand your dilemma correctly, you need to set another registry key as desired. Here's how it works; (Unless you have 3rd Party Keyboard Software Installed) After Bootup and Before Login, Windows reads the HKEY_USERS\.DEFAULT\Control Panel\Keyboard\InitialKeyboardIndicators because there is no user logged on. (0=Off, 2=On) After Logon, Windows Applies the setting from HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators (0=Off, 2=On) This setting is stored independantly indside each user profile, and the state from the Windows Session is saved at logoff. This means if you turn your NumLock on, a value of 2 is written at logoff, and NumLock will be toggled on at next login. Hope this helps.


On Sunday, July 4, 2004 at 5:30 am, John Burns wrote:
>
>Did you EVER find a solution for this - if so, I would really appreciate knowing
>what it was. Thanks.

[Reply or follow-up to this message]

Thank you Mike! This numlock issue has been aggravating me since I reinstalled my OS. You nailed it. All I did was set the value in the string you listed and my problem is solved...numlock on! Thanks again!


On Sunday, April 24, 2005 at 12:21 pm, Mike Jankowski wrote:
>Hi Guys,
>
>If I understand your dilemma correctly, you need to set another registry key as desired.
>Here's how it works; (Unless you have 3rd Party Keyboard Software Installed)
>
>After Bootup and Before Login, Windows reads the
>HKEY_USERS\.DEFAULT\Control Panel\Keyboard\InitialKeyboardIndicators because there
>is no user logged on. (0=Off, 2=On)
>
>After Logon, Windows Applies the setting from
>HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators (0=Off, 2=On)
>This setting is stored independantly indside each user profile, and the state from
>the Windows Session is saved at logoff. This means if you turn your NumLock on, a
>value of 2 is written at logoff, and NumLock will be toggled on at next login.
>
>Hope this helps.
>
>
>

[Reply or follow-up to this message]

On Sunday, May 8, 2005 at 11:22 pm, Michael wrote:
>I have a question about num lock AM using windows 2000 and I would like num lock in my Administrator profine to be on on boot up.
>Thanks Michael

[Reply or follow-up to this message]

I was having the problem but it is now fixed. In my first attemp to get my Num Lock to come on I started off with the easy fix, I tried the script method. That didn't work so I went through regedit. That worked for the start-up but then my num Lock would turn off. I fixed it by removing the script that I had created and only ran the regedit method.


On Sunday, June 9, 2002 at 11:22 pm, Ann wrote:
>I have a question about Force
>NumLock to Behave:

>I have done all that was suggested, including changing the value in the registry
>so that the numlock key will be on at bootup, but it still will not work. I can turn
>it on manually any time, but even though it comes on initially at bootup, once Windows
>xp loads, it goes off and stays off until I turn it on myself. Is there anything
>else I can try?
>
>

[Reply or follow-up to this message]

Your solution to the Force Numlock Key to stay on is ABSOLUTELY CORRECT. I have done some testing after doing some research on the internet. I did found out that HKEY_USERS\.DEFAULT\Control Panel\Keyboard\InitialKeyboardIndicators because there is no user logged on. (0=Off, 2=On) is before LOGON. Then HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators (0=Off, 2=On) is after logon. But I am unable to make changes to HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators after I read your posting here. This section This section "This setting is stored independantly inside each user profile, and the state from the Windows Session is saved at logoff. This means if you turn your NumLock on, a value of 2 is written at logoff, and NumLock will be toggled on at next login. Hope this helps" is very helpful. Thank you Mike Jankowski re: Question about 'Force NumLock to Behave' Sunday, April 24, 2005 at 12:21 pm Posted by Mike Jankowski (1 messages posted) Hi Guys, If I understand your dilemma correctly, you need to set another registry key as desired. Here's how it works; (Unless you have 3rd Party Keyboard Software Installed) After Bootup and Before Login, Windows reads the HKEY_USERS\.DEFAULT\Control Panel\Keyboard\InitialKeyboardIndicators because there is no user logged on. (0=Off, 2=On) After Logon, Windows Applies the setting from HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators (0=Off, 2=On) This setting is stored independantly indside each user profile, and the state from the Windows Session is saved at logoff. This means if you turn your NumLock on, a value of 2 is written at logoff, and NumLock will be toggled on at next login. Hope this helps.


On Sunday, July 4, 2004 at 5:30 am, John Burns wrote:
>
>Did you EVER find a solution for this - if so, I would really appreciate knowing
>what it was. Thanks.

[Reply or follow-up to this message]

YES, Thank you!! Changing the 'HKEY_USERS\.DEFAULT\Control Panel\Keyboard' from 0 to 2 worked perfectly for me, now the Numlock is always on from bootup to desktop. The numskulls at MS should give their head a shake, there should be a control panel setting for this!

[Reply or follow-up to this message]

These methods are great for ONE individual that logs onto a PC. But fail miserably in an AD environment where multiple people randomly log onto different machines. Here's why: Setting data to 2 under the reg key in the .Default sets the numlock on prior to logon. Then a NEW user logs in and numlock shuts off. The Current User key is now a different key than it was before, it's the current user. You can set the reg key to 2 under HKEY Current User and the next time they log in numlock will be on. But then user number 3 comes along and logs in for the first time, and low and behold the numlock shuts off. Again, set the value to 2 under HKEY Current User and the next time THAT user logs in they will have numlock on. Kind of a crappy solution when you have hundreds of users. The scripting method works, however when you're in an environment where that script will be removed by policy it's not a sure fire solution. One other option is like the scripting method, only put a REG file with the correct value in startup. But here's the only and best way to take care of it for WinXP: Create a local account and log onto the machine with it. Turn the numlock on (and make any other profile specific changes) then log off. Log on as the local admin and copy that newly created local profile to the Default User profile, allowing Everyone to access it. Now going forward any newly created profile will have Num Lock On. Of course, you'll need to recreate any exisiting profiles to inherit the new setting....


On Monday, October 15, 2007 at 6:47 am, Random wrote:
>YES, Thank you!! Changing the 'HKEY_USERS\.DEFAULT\Control Panel\Keyboard' from 0
>to 2 worked perfectly for me, now the Numlock is always on from bootup to desktop.
> The numskulls at MS should give their head a shake, there should be a control panel
>setting for this!

[Reply or follow-up to this message]

Yes I see your point, but this never was an issue before in previous operating systems. You would think NUMLOCK would follow the KISS system, if a user turns it on, it's ON the next time they login. You have to wonder why something that used too never be a problem, now requires someone with network administrator smarts to resolve.

[Reply or follow-up to this message]

Hello All,

Received the following question from Paul Turnberg;
-------------------------------------------------------
Q: I have a macro in a program - and every time it runs it turns on the NUM LOCK. 
 
The macro does use a sell object and sendkeys

Any idea why this would be happening?

I am a programmer.  You seem to know what you are doing, based on your reply in a 
thread, and I am at my wits end. Sorry to intrude on your time.  I will look into 
your book for sure.

Thanks
---------------------------------------------------------
A:
If this is an Outlook Macro, chances are you're experiencing a characteristic whereby 
you cannot send more than one character per "Sendkey" instruction. You may send seperate 
requests for each character, or use APIs. Refer to the following article for more 
information.

http://support.microsoft.com/kb/179987

Hope this helps.

Take Care,
Mike

P.S. - Will: The original solution does not "Fail miserably" in this "big" 100's 
of AD Accounts Environment! My environment has over 50000 users plus more objects. 
Would you really prefer to logon to each machine as you suggest or use an imaging 
solution? Not practical. The best way is to detect the Machine Type (Laptop or Desktop) 
then set the desired setting in both areas an for all future users with a Build Script. 
This is merely a different deployment method for the original solution which achieves 
the same as a Customized Default User Profile in a much more practical and dynamic 
way.






On Sunday, April 24, 2005 at 12:21 pm, Mike Jankowski wrote:

>Hi Guys,

>

>If I understand your dilemma correctly, you need to set another registry key as 
desired. 

>Here's how it works; (Unless you have 3rd Party Keyboard Software Installed)

>

>After Bootup and Before Login, Windows reads the 

>HKEY_USERS\.DEFAULT\Control Panel\Keyboard\InitialKeyboardIndicators because there 

>is no user logged on. (0=Off, 2=On)

>

>After Logon, Windows Applies the setting from

>HKEY_CURRENT_USER\Control Panel\Keyboard\InitialKeyboardIndicators (0=Off, 2=On) 

>This setting is stored independantly indside each user profile, and the state from 

>the Windows Session is saved at logoff. This means if you turn your NumLock on, 
a 

>value of 2 is written at logoff, and NumLock will be toggled on at next login.

>

>Hope this helps. 

>

>

> 

[Reply or follow-up to this message]

Oh thats funny. You read 'fail miserably' and stopped reading. Large environment has nothing to do with it. Imaging? Never said it..... Logging on to each machine? Not necessary. My statements still stand: over 100 users sharing less than 20 pc's=lots of profiles on each. Can't script a change or use policy here. Solution: update Default User Profile....only need to once, then copy that one to every machine with a quick batch file. Imaging? I wouldn't reimage to fix that, but I *would* update the image to include the correct profile... Having said that, I do agree with the original solution....IF you are able to script something at that site. A reg file in startup like I also offered up? Personally not a fan of that. But if you can't 'script' due to the limitations I described, then this is a sure-fire method. An alternative if you will.

[Reply or follow-up to this message]

Hey,

Great to see you're having fun! I didn't imply you had said imaging, note the separating 
conjunction...

I think I overshot your introducing the Default User point - this is quite valid. 
(Had to re-read original post...) However, you've misunderstood and hence incorrectly 
rejected part of my point yet also state similar. Points I wish to emphasize moving 
forward;

- It is best to fix the problem before it is experienced - at build time
- For those machines already in production, run a script from a Remote Machine
- In both cases - target only the specific objects you wish to customize. (NTUser.dat 
for one. Not the whole Default User Profile)

NumLock before login: (Per Machine)
- Controlled in .Default area of registry
- One setting read for all users of the machine
- Therefore fixed once per machine

NumLock after logon (Per User)
- Initially set inside the Default User Profile's Registry
- Copied from the Default User's Registry and stored in any new user's profile as 
they logon for the first time.
- Saved inside that specific user's profile at logoff
- Read from inside that specific user's profile at future logins

So the "Before Login" and "Default After Login" behaviours are what we might choose 
to address.

(No need to update existing profiles as users can operate the button themselves.)

I maintain then the Best Way to deploy the fix is to employ a Build Script. A Build 
Script is not a non-integral script which runs multiple times as the user logs on 
or starts up, (I'm not a fan of them either) but rather a Build Script executes One 
Time as the machine is dynamically built and does customize the behaviour as you 
will intend for All Future Profiles on every machine. Build scripts are effective 
within organizations leveraging Group Policy as they execute before the policy is 
applied.

The only situation a change might be necessary for machines already in production 
with Existing User Profiles is to address the "Default User - After Login" behaviour 
similar to what you've stated. For these, run the first part of the build script 
to change the default user behaviour specifically by copying a customized NTUser.dat 
to the Default User Profile Directory. (No need to do more.) Such a production script 
can be run from an admin machine reading a text file with all machine names and looping, 
or as a 3 week addition to your company login script. Group Policy could be set in 
a way preventing this, so recommend to temporarily revoke the interfering policy. 
(Foreign ownership could further interfere.) No need to address existing users who 
have likely determined what state they wish to have NumLock in.

Don't get me wrong, a Customized Default User Profile is neat and something I used 
to do, but I wish to convey it may be accomplished with less effort and in a way 
increasingly more ideal the larger the environment gets which I see as "fine tuning" 
the alternative you've generously presented.

Certainly different sized environments will qualify/disqualify certain methods. This 
is quite valid.

Thanks for Sharing Knowledge,
Mike







On Wednesday, March 12, 2008 at 9:09 am, will wrote:

>Oh thats funny.  You read 'fail miserably' and stopped reading.  Large environment 

>has nothing to do with it.  Imaging?  Never said it.....  Logging on to each machine? 

> Not necessary.

>

>My statements still stand:  over 100 users sharing less than 20 pc's=lots of profiles 

>on each.  Can't script a change or use policy here.  Solution: update Default User 

>Profile....only need to once, then copy that one to every machine with a quick batch 

>file.  Imaging?  I wouldn't reimage to fix that, but I *would* update the image 
to 

>include the correct profile...

>

>Having said that, I do agree with the original solution....IF you are able to script 

>something at that site.  A reg file in startup like I also offered up?  Personally 

>not a fan of that.  But if you can't 'script'  due to the limitations I described, 

>then this is a sure-fire method.  An alternative if you will. 

[Reply or follow-up to this message]

Ok, for those of you with users using multiple machines, try this.  It only works 
if you have Word installed, but I couldn't find an alternate method (not that I tried 
hard).  Also, to fire a .vbs file from a login batch script, just enter it like an 
.exe file; for instance, "\\MyServer\Logins\NumOn.vbs".

For those of you who just have one computer, the simple way is to just let Windows 
automatically restore the previous Numlock condition on login, but if that doesn't 
work, you can either set one of these scripts in the Startup folder or add a pointer 
in the registry at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\.

1. Set the .DEFAULT user on all the machines as desired using the registry when you 
image them.
2. Since the default for each user is to be on automatically (on my machine anyways) 
users who want Numlock On each time they login are left alone.
3. For the users who want Numlock Off each time they login, run the following .vbs 
file from their login script (yes, I know it's a really dumb-looking script, but 
the only way I know how):

Set WshShell = WScript.CreateObject("WScript.Shell")
Dim NumOn
Set objWord = CreateObject("Word.Application")
NumOn = objWord.NumLock
objWord.Quit
If NumOn = -1 Then
            WshShell.SendKeys "{NUMLOCK}"
End If

Note: if your machines default to Numlock Off, put the same script in the login scripts 
of those who want it on instead of those who want it off, but change "If NumOn = 
-1" to "If NumOn = 0".  Alternately, you could just run both scripts to be sure.

Also, this requires at least two login scripts per user type (one with the Numlock 
change and one without), so if you have a dozen login scripts (say, one for engineers, 
one for execs, etc.), it could be cumbersome.  However, it should get the job done 
without too much extra work, since you just set the script once in the user's profile 
and you're done.

When you change a script for whatever reason, just make the changes to the one with 
the NumOn/NumOff Entry, save, delete the entry, save as, done.  If using both a NumOn 
and NumOff script, make changes, save, change Off to On or vice versa (if you name 
the scripts NumOff/NumOn), save as, done.

[Reply or follow-up to this message]

Here's another version of the VBS script I cobbled together.
I found that in my case at least launching an instance of Word when Word
was already running opens another Word window, screaming about
normal.dot already being in use. So this script checks first.

Tip of the hats for code tips to:
http://www.mvps.org/scripting/rube/index.htm
http://www.windowsitlibrary.com/Content/1258/09/1.html

If IsNumLocked = 0 Then
  NumLockOn
End If

Function NumLockOn()
set WshShell = CreateObject("WScript.Shell")
WshShell.SendKeys "{NUMLOCK}"
End Function

Function IsNumLocked()
Dim oWrd
Dim bWrdOff
bWrdOff = False




On Error Resume Next
Set oWrd = GetObject(, "Word.Application")
If Err Then
   Err.Clear
   Set oWrd = CreateObject("Word.Application")
   bWrdOff = True
End If
IsNumLocked = oWrd.Numlock
If bWrdOff Then
   oWrd.Application.Quit True
End If
End Function

In my situation my office PC is on and logged in 24-7, but for whatever reason (RDP?)
the NumLock is off every morning.
I added this to Scheduled Tasks to run every time the PC is idle for more than an 
hour.

[Reply or follow-up to this message]

Reposting the code since the spacing was garbled:

If IsNumLocked = 0 Then
  NumLockOn
End If

Function NumLockOn()
set WshShell = CreateObject("WScript.Shell")
WshShell.SendKeys "{NUMLOCK}"
End Function

Function IsNumLocked()
Dim oWrd
Dim bWrdOff
bWrdOff = False
 On Error Resume Next
Set oWrd = GetObject(, "Word.Application")
If Err Then
   Err.Clear
   Set oWrd = CreateObject("Word.Application")
   bWrdOff = True
End If
IsNumLocked = oWrd.Numlock
If bWrdOff Then
   oWrd.Application.Quit True
End If
End Function







On Thursday, May 22, 2008 at 2:28 pm, Chris O. wrote:

>Here's another version of the VBS script I cobbled together.
 

[Reply or follow-up to this message]

• Search this forum
• Start a new thread on a different subject

• Report abuse of the forum