Note on archived topics.
06-14-2013 09:05 AM
WSD stands for Web Services for Devices. In the case of the WSD Port Monitor, there are 3 services that make a difference. WS-Discovery makes it possible for the Port Monitor to discover (and rediscover) a printer and its address. WS-Eventing makes it possible for the printer to send notification of changes that the port monitor (and the user) might need to know about. WS-Print makes it possible for the port monitor to print jobs and to get information about the configuration and status of the printer and to control the job if needed.
So how do these services make WSDMon different from TCPMon?
- Setup and Discovery - TCPMon is setup by a user (or software run by the user) that knows the IP address of the printer. If that address ever changes then it loses the printer. WSDMon can automatically install the printer when it is connected because it announces itself via WS-Discovery. It also checks the address of the printer with each print job so it is connected even if the address changes.
- Status Updates - TCPMon periodically (like every 10 minutes) polls the device status using SNMP to get updated status. WSDMon subscribes for printer events so that it gets updates immediately. It can tell you if there is a jam, no paper, out of ink/toner, etc. when it happens.
- Print Jobs - TCPMon prints via port 9100 and simply sends the data. There is very little, if any, feedback about whether the printer is ready to receive the data or who it is coming from. You don't have information that you could use to cancel the job, etc. WSDMon sends a request to create a job and gets back an identifier to use to monitor and control the job. It then sends the data when the printer is ready for it.
Windows 8 enables WSDMon automatically. This means that you get a new printer on your computer when you connect it to the network - no other setup is necessary. That would not be very good in an enterprise situation because there may be hundreds of printers close enough to fill your printers folder. If there are more than 30 (a somewhat arbitrary number) printers then the process shuts itself off and you need to add the printer by IP address again. Whichever way it gets setup, you still get the rediscovery, eventing and print job control that TCPMon lacks.
WSDMon will only work with printers that support the WSD services. This should be everything released in the last 5 years or so.
07-11-2013 05:34 PM
My hope was to find some way to look at the device on the other end of this WSD port, like a Printer Device that shows your toner level, machine status etc. I would appreciate any recommendation on how to do this. Currently I use an IP address in a browser to bring up the interface. How do you do this with a WSD port?!??\
07-12-2013 08:00 AM
If you are running on Windows 8, then I would recommend the HP Printer Control app. It will show you the status of all of your network connected printers. I don't believe that we have anything that will do the same for Windows 7 or before at this time. If you are looking to write a program to do this, then I would recommend that you look at the IBidiSpl API that is published in all recent versions of Windows (wsdmon is supported starting in Windows Vista). I have a test application that I use to query the data with that interface but nothing that is intended to be customer facing production code.
02-25-2014 01:28 PM
Could the idea of a phone book be a way to explain what WSD does. It gets information from each printer and creates a "phone" directory of all the printers. Then when you need to settup one of the printers it can look at that list (directory) to find the printer and the settings.
02-25-2014 01:52 PM
Not quite. A phonebook would be static data (i.e. published only occasionally). WSD is live data - it would be more like an online directory than a phonebook. The printer advertises itself when it connects. The client (in this case the Microsoft WSDMon port monitor) validates the address each time that it connects so it is always correct.
In an enterprise environment where there are many printers then there can be a service that acts more like your live directory where it keeps track of the correct data and clients can ask it for the current address or other information.
The client does remember a unique ID value that the printer has and it can use that to ask the printer "what is your current address" each time that it needs it.
By the way, this is the advantage over the TCP/IP port monitor. It has static address data. If the printer gets a dynamic address from a domain name server then it will eventually change and break the TCP/IP connection. WSDMon will not break like that.
06-24-2015 11:16 AM
The reason that I found this thread was that I was having problems with printers using WSD ports. All of the explanations are interesting however I don't think they really help in a practical situation. What I found is that any printer configured with a WSD port in the printer port settings has far more issues than printers which use straight TCP IP version 4 addresses.
I mention ipv4 because I think that somehow the WSD port automatically switches to ipv6 for some reason. And ipv6 has its own issues especially in small LAN environments. creating or using the proper ipv4 port always solves the problem and prevents the mysterious offline printer issue from happening again. Maybe we're getting to the point where all this added functionality is detrimental and the good old simple solution is the right solution.
Has anyone else experienced a similar situation?
10-12-2015 01:46 PM
Emphatically yes agreed. Recently had a power event with a server chassis that houses the print server. Three identical printers; two of which using their respective TCP/IP ports and the other the WSD port. Take a guess at which one failed to come back online without manual intervention...
Came across this thread trying to find benefits of WSD but I have also come to the conclusion that it is less stable than TCP/IP and that is enough for us not to use it at any of our client's offices (as an MSP).
10-26-2015 10:58 AM
This has been happening to me as well, but not if I install "Local Printer" If I choose "Add a network printer" and then create the tcp/ip port at that screen I get a call that the printer is not working. I haven't done any solid testing to see if this is the case. It just seems that way to me.
11-25-2015 01:26 PM
I just had this issue occur today, two relatively new Windows laptops with Win10, they were originally setup in a small office, saw the older Kyocera CopyStar 300ci printer, perhaps due to the Kyocera driver installation process helping to find it correctly. All was well for 2 weeks, then, both Win10 laptops apparently lost ability to print.
When I looked into the printer device settings, I was suprised that it was this WSD not TCP/IPv4 as I would have expected. I'm not certain, but I also noted a really long string that almost looked like IPv6, which is disabled on the printer and should not be on the LAN at all as far as I'm aware (I believe the IPv6 was also disabled on the LAN's router as IPv6 has unfortunately been the cause of so many real world issues, better off without it within the small business environment LAN generally).
I attempted to re-add the printer, and the auto-detect didn't see it at all now. I deleted the old printer queue, attempted to re-add, and still not seen.
So, I simply added the printer manually via TCP/IPv4 static IP address (I made sure the printer is on a static IP), and now it's working perfectly fine again.