Print Server using Windows Server Core

Introduction

Many administrators are always looking for ways to simplify the required management of their environments, save on overhead, resources, etc. With the advent of Windows PowerShell and it growing to be a commonplace administrator utility in Windows environments, simple systems such as print servers no longer really require a full-fledged graphical user interface. Print servers are prime candidates to be hosted on the CLI-based Windows Server Core variant of Windows Server, especially where they are so easily managed through remote PowerShell. In this brief article, we’ll take a quick look at spinning up a core print server and some of the options available for administering the new server.

Spinning up your machine

Whether you are using traditional hardware for your server (a rackmount server, blade server,tower server/desktop PC) or a virtualized environment, you’ll first need to actually install Windows Server Core on your machine. For my environment, I spun up a virtual machine in my Proxmox virtual environment, but many may be using VMware, Hyper-V, or other solutions which will work perfectly fine.

Adding the features and roles to the server

Once you have Windows installed and your requisite network and domain configuration done, add the necessary services and features to the server:

Install-WindowsFeature Print-Services

This will install the Print Services role as well as the Print Server Role Service. No further configuration is necessary as far as the services and features go. All that is left to do is add some printers!

Administering the server

There are multiple ways to administer your new Windows Core print server.

PowerShell

Arguably the correct way to manage a Windows Core server, is PowerShell. Like other deployments, a print server is managable through the command line with general ease. Beginning with Server 2012’s Core version, there are many print management commands available to administrators.

As an example, we can configure a printer using just two commands:

Adding the printer port: Add-PrinterPort -Name "192.168.254.5" -PrinterHostAddress "192.168.254.5"

Adding, sharing, and publishing the printer: Add-Printer -Name YourPrinter01 -DriverName "HP Universal Print Driver PCL6" -PortName 192.168.254.5 -Shared -ShareName "YourPrinter01" -Published

VBS

An archaic option also exists. At C:\Windows\System32\Printing_Admin_Scripts you’ll find a variety of VBS scripts that can be used to administer the print server. But seriously, who is preferring VBS when we have PowerShell?

As an example, we can configure a printer using the following commands:

Creating the printer port: cscript prnport.vbs -a -r 192.168.254.5 -h 192.168.254.5 -o raw

Adding a printer on the above printer port: cscript prnmngr.vbs -a -p YourPrinter01 -m "HP Universal Print Driver PCL6" -r 192.168.254.5

Sharing the above printer: cscript prncnfg.vbs -t -p YourPrinter01 -r 192.168.254.5 -h YourPrinter01 +shared -direct -m "Default printer for HR" -l "YourDesiredLocation"

Publishing the printer to Active Directory: cscript pubprn.vbs \\printserver\YourPrinter01 "LDAP://CN=YourContainer,DC=YourDomain,DC=com"

GUI

If you really just can’t let go of using the graphical user interface just yet as you ease into command-line-based administration you can still get your hands on the GUI by executing: C:\Windows\System32\printui.exe /il

Additionally, on a remote machine, you can connect RSAT to your Windows Core print server and use the Print Management snap-in for the Microsoft Management Console to visually administer the print server.

But seriously…get comfortable with PowerShell. This is the way.

Conclusion

And, well, that’s pretty much it. There is certainly a more granular level of detail we could go into, but for the purposes of a general overview, I think that does it. Windows Core servers are quick and easy to spin up and an absolute breeze to configure if you are comfortable with PowerShell. In a lab environment, they can also be a great way to get more comfortable with PowerShell if you are just learning. Go ahead and spin up a Windows Core server in VirtualBox or your choice of virtualization bench and give it a try!

What are you using core servers for in your environment, and how do you like it? I’d love to hear from you in the comments below.


Additional Reading

Install Print and Document Services | Microsoft Docs

Using Server Core as a Print Server – Microsoft Tech Community

Using PowerShell to Add a Network Printer for All Users of a Computer

Purpose

This brief article details the commands necessary to use PowerShell to add/install/map a network printer for all users of a computer.

Prerequisites

The below actions require the executing user to have administrative rights to the workstation in question.

Solution

Establish a Remote PowerShell session

In an elevated PowerShell session (running as administrator), run the following command;

Enter-PsSession -ComputerName HOSTNAME.FQDN

where HOSTNAME.FQDN is the fully-qualified domain name of the workstation in question.

Example: desktop01.yourdomain.com

You can actually execute this process using the short name of the computer instead of the FQDN.

Remove the network printer for all users

Once you’ve entered the remote PowerShell session successfully, run the following commands in sequence;

RUNDLL32 PRINTUI.DLL,PrintUIEntry /ga /n\\PRINTSERVER\Shared-printer

where PRINTSERVER is the NETBIOS name of your print server from which the printer is shared and Shared-printer is the shared name of the printer you’d like to add/install/map.

When this is complete, the network printer should be uninstalled/removed for all users on that workstation. This can be verified by having users logon and check their Devices and Printers window.

Using PowerShell to Remove a Network Printer for All Users of a Computer

Purpose

This brief article details the commands necessary to use PowerShell to remove a network printer for all users of a computer.

Prerequisites

The below actions require the executing user to be an administrator of the remote workstation, or a Domain Administrator.

Solution

Establish a Remote PowerShell session

In an elevated PowerShell session (running as administrator), run the following command;

Enter-PsSession -ComputerName HOSTNAME.FQDN

where HOSTNAME.FQDN is the fully-qualified domain name of the workstation in question.

Example: desktop01.yourdomain.com

You can actually perform these commands without using the FQDN, and using the short name instead.

Remove the network printer for all users

Once you’ve entered the remote PowerShell session successfully, run the following commands in sequence;

Get-WmiObject -Class Win32_Printer | where{$_.Name -eq ‘\\PRINTSERVER\Shared-printer‘}

where PRINTSERVER is the NETBIOS name of your print server from which the printer is shared and Shared-printer is the shared name of the printer you’d like to remove. This command will return the printer that you’d like to remove, if it is installed for the user running the command. Even if the user running the command does not have this printer installed, this process will still work as intended.

Get-WmiObject -Class Win32_Printer | where{$_.Name -eq ‘\\PRINTSERVER\Shared-printer‘}| foreach{$_.delete()}

again, where PRINTSERVER is the NETBIOS name of your print server from which the printer is shared and Shared-printer is the shared name of the printer you’d like to remove.

When this is complete, the network printer should be uninstalled/removed for all users on that workstation. This can be verified by having users logon and check their Devices and Printers window.

Fix Windows Mobile Device Center Hanging at Launch and Mobile Devices Will Not Connect

While Windows Mobile Device Center is largely considered a thing of the past in many environments, there are plenty of industries and situations where it is still used to connect and sync mobile devices such as Intermec scanners to other systems. With Windows 10 Update 1703, there was a change regarding svchost.exe that can cause this issue. In this blog post, I’ll explore the two changes I’ve discovered that have worked for me to resolve this issue.

Introduction

While Windows Mobile Device Center is largely considered a thing of the past in many environments, there are plenty of industries and situations where it is still used to connect and sync mobile devices such as Intermec scanners to other systems. With Windows 10 Update 1703, there was a change regarding svchost.exe that can cause this issue. In this blog post, I’ll explore the two changes I’ve discovered that have worked for me to resolve this issue.

Prerequisites

To resolve this issue, access to a local account on the affected device which is a member of the Local Administrators NT group is required.

Problem

When the Windows Mobile Device Center is launched, the splash screen appears and hangs at “Please wait while Windows Mobile Device Center starts…”

Additionally, if the application does launch successfully, mobile devices may show connected on the mobile devices’ screens, but the Windows Mobile Device Center will show them as “Not Connected.”

Environment

Workstations with Windows 10 Professional or Enterprise Version 1703 or newer and Windows Mobile Device Center installed. This issue is operating system architecture agnostic. Affected workstations have Intermec handheld computers seated in their dock, which is attached to the affected workstation via USB cable.

Cause

Update 1703 for Windows 10, like other Windows updates, may revert older version of .NET Frameworks to be disabled; additionally, Update 1703 also has a new feature related to svchost.exe: the services will not share by default the same svchost.exe, even they are assigned to be run within of the same group with -k option. More detailed has been described in the winhelponline.com article under the Additional Reading section of this article.

Rapimgr and Wcescomm (Windows Mobile-based device connectivity and Windows Mobile-2003-based device connectivity) are such services: they are defined to be started in the same shared svchost.exe (-k WindowsMobile). RapiMgr creates a kernel semaphore AS_ACCEPTANCE_SEMA, because it starts first.  WcesComm tries to do this too, but fails: the semaphore has been already created and should be only opened. This will fail: not enough permissions (remember: two different svchost.exe, different SID, etc). So, wcescomm is just stopped.

Solution(s)

Enabling .NET Framework 3.5 Completely

Strike Win+R on the keyboard, and in the resulting Run Prompt, type appwiz.cpl then strike the Enter/Return key on the keyboard.

In the resulting Programs and Features window, select the Turn Windows features on or off option from the navigation pane at the left side of the window.

In the resulting Windows Features window, expand the option for .NET Framework 3.5 (includes .NET 2.0 and 3.0), then ensure it’s check box is fully enabled with a check mark–not a filled square–and that you do the same for the two child items, Windows Communication Foundation HTTP Activation and Windows Communications Foundation Non-HTTP Activation, then click OK. Windows will take a few moments to enable the selected features.

At this point, it is recommended that you restart/reboot the workstation.

Adding “SvcHostSplit Disable” in the System Registry

Warning: Editing the system’s registry can be dangerous unless you know exactly what you are doing. It is advisable that if a solution exists without editing the registry, that it be the selected resolution. If editing the registry is required, always export a backup of the working registry to both the local hard drive as well as removable storage prior to proceeding. Alternatively, a System Restore Point may be set.

Strike Win+R on the keyboard, and in the resulting Run Prompt, type regedit then strike the Enter/Return key on the keyboard.

In the resulting Registry Editor window, select File from the menu bar at the top of the window, then Export to save a backup of the affected workstation’s registry. When completed, close the Registry Editor.

Open an elevated Command Prompt shell (running as administrator. This can be done by clicking the Start Menu icon on the Taskbar in the bottom-left corner of the desktop environment and typing cmd then right-clicking the Command Prompt result and selecting Run as Administrator. Note that this must be done from a local account that is a member of the Local Administrators NT group on the affected workstation. Alternatively, you may browse to C:\WINDOWS\System32 and right-click cmd.exe and select Run as Administrator.

In the resulting Administrator: Command Prompt window, paste the below commands in and strike the Enter/Return key in sequence.

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\RapiMgr /v SvcHostSplitDisable /t REG_DWORD /d 1 /f1 REG ADD HKLM\SYSTEM\CurrentControlSet\Services\WcesComm /v SvcHostSplitDisable /t REG_DWORD /d 1 /f

When completed, you may close the Administrator: Command Prompt window.

Verifying Service Properties

Strike Win+R on the keyboard, and in the resulting Run Prompt, type services.msc then strike the Enter/Return key on the keyboard.

In the resulting Services window, locate the Windows Mobile-based device connectivity and Windows Mobile-2003-based device connectivity services. For each, do the following:

Right-click the desired service and from the context menu, select Properties.

In the Log On tab, ensure the second radio button is selected and that the This account: field displays Local Service. If the Local System account radio button is selected, you’ll need to change the selection to the second option and enter Local System in the This account: field. The password is blank. When complete, click Apply.

In the Recovery tab, ensure the drop-down menus for First failure:, Second failure:, and Subsequent failures: all have Restart the Service selected. When complete, click Apply.

When complete, click OK to close the Properties window for the service.

At this point, a reboot/restart of the affected workstation is required.

Upon startup, the Windows Mobile Device Center should launch normally when the Start Menu entry or desktop shortcut is clicked. Once the WMDC window is open and, subsequently, the Intermec mobile computer is docked, you should see the device begin to connect; this is indicated by a spinning green icon in the bottom-left quadrant of the Windows Mobile Device Center window. The device should then connect and use of Advantage Scan on the Intermec and Drop Utility on the affected workstation may be resumed.


Additional reading

https://social.technet.microsoft.com/Forums/office/en-US/9cab3e8e-6cc4-48e4-8ed9-d595bc83f04b/windows-mobile-device-centre

https://www.winhelponline.com/blog/view-resources-usage-each-service-svchost-windows-10/