Migrating a Windows Print Server from Server 2016 to Server 2025

Printing is not usually the most exciting part of IT support, but when it stops working, everyone notices very quickly.

We recently worked through a print server migration from Windows Server 2016 to Windows Server 2025 for a small business environment. The existing setup was fairly typical: one central server acting as the print server, with a shared Develop multifunction printer installed manually on client PCs.

The goal was to move the printer from the old server to the new one, deploy it automatically using Group Policy, and remove the old printer connection from users’ computers.

For businesses in Oxford, Oxfordshire, Bicester and Buckinghamshire, this is the sort of background IT work that can make day-to-day operations much smoother. It is not glamorous, but it avoids users having to manually add printers, guess which printer to use, or rely on outdated server connections.

The Starting Point

The original print server was hosted on the old Windows Server 2016 machine, with the printer shared from there. Client PCs had the printer installed using the old server path, something like:

\\OldServer\PrinterName

The new Windows Server 2025 server had already been prepared, so the next step was to recreate the shared printer there, using the correct manufacturer driver rather than relying on a basic Microsoft class driver.

That last point mattered. Many multifunction printers have features such as:

• Duplex printing
• Colour and mono controls
• Paper tray selection
• Secure print
• Account tracking
• Finishing options such as stapling or sorting

If the wrong driver is used, some of these features may disappear or behave differently. That can be frustrating for users and can also create extra support calls.

Choosing the Printer Driver

For this migration, we tested the Develop Universal V4 PCL driver.

V4 printer drivers are the newer Windows print driver model. They are generally cleaner from a deployment point of view and are designed to work well with modern Windows print environments.

In the past, I would often be cautious with V4 drivers for multifunction printers because they can sometimes expose fewer advanced options than traditional manufacturer drivers. However, in this case, the Develop V4 driver appeared to provide the full driver interface and the required printer functionality.

That made it a good fit for this setup. We still checked the printer preferences carefully from a client PC after deployment, rather than assuming the driver would expose everything correctly.

Creating the New Shared Printer

On the new server, the printer was added using the printer’s network IP address and shared with a clean, consistent share name.

The new printer path became something like:

\\NewServer\PrinterName

Once the printer was installed on the new server, we tested printing directly from the server first. After that, we connected to the shared printer manually from a client PC to confirm that:

• The printer installed correctly
• The driver loaded properly
• The full printer preferences interface was available
• Test pages printed successfully
• The printer was clearly using the new server path

This step is important. It is much easier to fix driver or queue problems before Group Policy pushes the printer out to every user.

Deploying the Printer with Group Policy

The previous printer had been installed manually, so the new approach was to use Group Policy Preferences.

For a shared printer path such as:

\\NewServer\PrinterName

The correct place to configure it is:

User Configuration > Preferences > Control Panel Settings > Printers

A new Shared Printer item was created with the action set to Update. This allowed the new printer connection to be added automatically when users signed in.

Using Group Policy for printer deployment makes future changes much easier. If the printer share name, server name or printer settings change again in the future, they can be managed centrally rather than visiting each PC manually.

This is especially useful for small businesses in Oxfordshire and Buckinghamshire that may not have in-house IT staff but still need reliable Windows Server support and practical day-to-day IT management.

Removing the Old Printer Connection

The next step was removing the old printer from client PCs.

A second Group Policy Preference item was created, this time with the action set to Delete, targeting the old shared printer path.

One important lesson from this part of the process: the path has to match exactly.

In this case, the old printer connection used the server’s fully qualified domain name:

\\OldServer.domain.local\PrinterName

The first removal attempt used a shorter server name, so the old printer did not get removed. Once the delete entry was updated to match the exact printer connection path shown on the client PC, the old printer disappeared correctly.

That is a useful reminder: when removing old shared printers by Group Policy, always check the exact printer name on the workstation.

A quick PowerShell check can help here:

Get-Printer | Select-Object Name, Type, DriverName, PortName

Confirming the New Printer Was in Use

After the Group Policy update, the client PC showed only the new printer connection:

\\NewServer\PrinterName

The old server connection was gone.

We also checked the driver shown on the client and compared it with the driver configured on the new print server. This confirmed that the workstation was using the new shared printer from the new server.

It is possible for old printer drivers to remain in the local Windows driver store, but that does not necessarily mean the old printer is still in use. The key things to check are:

• the printer name/path points to the new server
• the old printer connection is gone
• the print queue on the new server uses the intended driver
• test prints are processed through the new server

Checking Print Job Logging

As part of the tidy-up, print job logging was also checked.

Windows print job history is normally found here:

Event Viewer > Applications and Services Logs > Microsoft > Windows > PrintService > Operational

The key event for completed print jobs is:

Event ID 307

This can show useful details such as who printed, which printer was used, and how many pages were printed. Please note, the PrintService Operational log needs to be enabled first.

Final Result

The migration achieved the intended outcome:

• The printer was moved from the old Windows Server 2016 server to the new Windows Server 2025 server
• The printer was deployed automatically via Group Policy
• The old printer connection was removed from client PCs
• The Develop Universal V4 PCL driver was used
• The V4 driver appeared to provide the full required printer functionality
• Print job logging was checked on the new server

IT Support for Small Businesses in Oxfordshire and Buckinghamshire

At AGGIA IT Services, we provide practical IT support for small businesses, sole traders and home-based professionals across Bicester, Oxford, Oxfordshire and Buckinghamshire.

We help with Windows Server support, Microsoft 365, Group Policy, network printers, backups, security, migrations and day-to-day IT troubleshooting.

If your business is still relying on older server infrastructure, manually configured printers or outdated IT processes, it may be worth reviewing the setup before it becomes a problem.

Need help with Windows Server, Microsoft 365 or business IT support in Oxfordshire or Buckinghamshire? Get in touch with AGGIA IT Services for friendly, practical and reliable support.