Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Good Morning AskPerf Readers! Welcome to Day Ten of our Launch Series. Our theme this week has been Printing, and today we’ll be continuing in that vein. Our topic today is Location-Aware Printing. Mobile users and network-connected devices are a rapidly increasing component in the enterprise environment. Mobile users are not only sales and customer facing users that travel, but also remote users that work outside the office or users that work from home outside of business hours.
Given this increasing trend towards mobility coupled with the predicted increase in shared / networked printers in a home environment due to products such as Windows Home Server, the HomeGroup feature in Windows 7 and the numerous print server appliances currently available and I’m sure you can see why it is so important to have default printers “just work” in a logical and intuitive fashion – regardless of the user’s location. Windows 7 provides a new tool, Location-Aware Printing (also known as “Smart Default Printer”) that allows mobile users to configure per-network default printers so that as they connect to different networks, their default printer is updated. In addition, there are some enhancements to the consistency with which the default printer is determined that have been incorporated into the spooler on Windows 7 and Windows Server 2008 R2. One quick note – even though the spooler changes affect both operating systems, the new Location-Aware Printing feature only applies to Windows 7 mobile devices.
Location-Aware Printing depends on the Network Location Awareness services and the Network List Services to determine which network (or networks), to which the laptop is connected. Using the Network List Manager API’s, you can enumerate either networks or network connections. For this feature, networks are enumerated. So, if a user is connected to a managed corporate network, either via wired or wireless connection, the same corporate domain network is detected regardless of the specific network connection used. However, if a user is connected to a different wired and wireless network, there is an order of preference used to resolve the conflict:
When walking through the logic, the registry key to keep an eye on is HKCU\Printers\Defaults. The print spooler service determines and sets the default printer for users in similar ways at different times. Let’s take a look at the logic for the user logon scenario.
The image below shows the process flow:
When the Print Spooler Service starts, such as during a Windows startup or restart, it is not aware of what user (if any) is logged on. It performs the user logon steps above for every user whose profile ahs been loaded from HKEY_USERS. If there are no interactive users logged (such as during boot), then the steps will typically be performed for services accounts such as Local Service and Network Service. For these accounts, the Disabled registry value and the GUID-named subkeys typically will not exist. Therefore, no changes will be made to the default printer value in Device for each account.
That brings us to the end of this post. Just to recap the most important points:
Enjoy the rest of your Saturday. I’ll be back tomorrow with an overview of Distributed Scan Management. Until next time …
- CC Hameed
Often, we have users traveling to various offices within the same Domain network. Can Location-Aware Printing be made aware of different locations within the same domain? For example, can it use different octets of the laptop’s IP address to determine location?
How about default printer preferences? The default on the server is not promulgated to the clients.
Like Doug, I am regularly switching between home, hotel, and two or more corporate offices that are in the same domain. Windows 7 is only enumerating the one corporate network and so I don't get the right default default when I go into the "other" office. Is there any way to associate a sub-net to the network that is being identified to fix this?
The networks are typically defined by the domain name, or in the case of unmanaged networks - by the name of the Access Point. There's no way to associate them with a specific subnet in the current implementation.
Excellent feedback though!