Welcome to Microsoft Q&A!
Thank you for taking the time to provide these details.
Based on your description, this behavior sounds less like a standard user policy and more like a Device Installation Restriction policy that was configured to allow only specific device IDs, device instance IDs, or device classes. In environments where these policies have been heavily customized, Windows may only recognize the originally installed keyboard and mouse, sometimes even when connected to specific USB ports. As a result, replacement devices can work during POST/BIOS but stop functioning once Windows loads.
Since gpresult does not show any obvious device restrictions and the corresponding settings appear as Not Configured in Group Policy Editor, I would recommend investigating further through Resultant Set of Policy (RSOP), Event Viewer, and the registry.
1. Review Device Installation policies in RSOP
Run: rsop.msc
Then navigate to: Computer Configuration→Administrative Templates→System→Device Installation→Device Installation Restrictions
Pay particular attention to the following settings:
- Prevent installation of devices that match any of these device IDs
- Prevent installation of devices that match any of these device instance IDs
- Prevent installation of devices using drivers that match these device setup classes
- Prevent installation of removable devices
- Prevent installation of devices not described by other policy settings
- Allow installation of devices that match any of these device IDs
- Allow installation of devices using drivers that match these device setup classes
Even if the original GPO is no longer visible or currently shows as Not Configured, RSOP can help identify the effective policy settings that were applied to the computer.
2. Check Device Setup logs in Event Viewer
Open Event Viewer and browse to:
Applications and Services Logs→Microsoft→Windows→DeviceSetupManager→Admin
Look for events containing messages such as:
- "blocked by PnP restriction policy"
- "installation prevented by policy"
- References to device IDs (VID/PID values)
These events can often indicate exactly which policy, or restriction prevented the device from being installed.
3. Examine the registry
Device installation restrictions are commonly stored under:
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions
Check for entries such as:
- DenyUnspecified
- AllowDeviceIDs
- DenyDeviceIDs
- AllowDeviceClasses
- DenyDeviceClasses
If these values are populated, they may be enforcing restrictions even if the original Group Policy is no longer easy to locate.
4. Consider a clean installation before donation
Because these systems are running Windows 7 and will be donated, the simplest and most reliable approach may be to:
- Remove the computers from the domain.
- Back up any data that needs to be retained.
- Perform a clean Windows installation (or factory recovery if available).
This removes domain policies, local policies, device restriction settings, and legacy hardware configurations, helping ensure the recipients can use standard keyboards, mice, and USB devices without encountering these restrictions.
5. If you plan to keep the existing installation
- Generate a full Group Policy report:
gpresult /h C:\gp.html
- Review the
Computer Configuration → Administrative Templates → System → Device Installation section carefully.
You may also want to export the registry key mentioned above and verify whether any restriction settings remain.
Based on the symptoms you described, my initial suspicion would be a historical Device Installation Restrictions configuration using device instance IDs, or a "deny all except approved devices" policy that was implemented years ago and has remained in effect.
Reference: Manage Device Installation with Group Policy | Microsoft Learn
I hope this helps point you in the right direction. If you find this information helpful, please consider clicking Accept Answer.
Thank you for using Microsoft Q&A.