Jump to content

Recommended Posts

Posted

Hi all,

It started last week, the click box for the "Share this printer" randomly unclicks itself. It keeps happening randomly!

 

No one in school can print, and I can't find anything in the logs, I think at this point I think it is Aliens

rimmer-aliens.gif

 

printer share.png

 

Has anyone got any ideas?

 

many thanks

Posted
The only thing I can think of at the moment is a windows update that is causing the issue or a issue with a 3rd party print product (eg Papercut). Is the server fully up to date? Or when was the last time you did updates compared to when the problem started happening?
Posted

Hi,

the issue started last Friday, I did a backup restore from two weeks ago. everything worked for about 2 days and yesterday it happened mid-morning again twice today. I've done a full update yesterday afternoon.

 

I'm running a SFC / Scannow and seeing if anything pops up

Posted

so last week the share kept randomly turning off every few hours.

 

what I did that seems to be working now.

 

turn off the share, Saved it.

 

turn on the share, saved it.

 

 

so far it's been on since Friday afternoon and now till Monday morning.

 

My fingers are crossed it stays on.

Posted

Same here!! Been driving me mad today!! We've created a script which runs every minute to re-enable the share.

 

For anyone who wants it:

Set-Printer -Name "follow Me Printer" -Shared $True -Published $True -ShareName "Follow Me Printer"

  • Thanks 1
Posted

@stevenlong1985 - I figured out what was doing ours but literally no idea why! If you go to - Event Viewer (of print server) > Application and Services Logs > Microsoft > Windows > PrintService > Operational. Right click and select Enable. This enables a line by line insight into whats going on. It will say in there something like 'Unsharing printer' and give the account GUID that unshared it.

 

Turns out it was mine!! :censored: so I have since blanked and installed a fresh windows 11 on my PC and hasn't happened since! (and it was unsharing every 10 minutes for us!)

  • Thanks 1
  • 2 months later...
Posted
I have this same issue. I've enabled operational logging and can see the user that's unshared the printer, its a random service account that isn't related to printer at all (checked all the involved services). The computer name is given as the print server itself. There is nothing in the security logs for this account suggesting a logon event has occurred. No profile on the server for this user. Any ideas?
Posted
I have this same issue. I've enabled operational logging and can see the user that's unshared the printer, its a random service account that isn't related to printer at all (checked all the involved services). The computer name is given as the print server itself. There is nothing in the security logs for this account suggesting a logon event has occurred. No profile on the server for this user. Any ideas?

 

Has the Print Server got Print Deploy installed?

Posted

Not exactly.

 

We've got the issue where there is a link between MY user account and Print Deploy. If I log on anywhere with Print Deploy software installed. It'll kill any of the printers which are deployed via Print Deploy to the workstation.

 

I would uninstall Print Deploy client from your Print Server to start with. If that service account has logged on anywhere with Print Deploy installed, i'm guessing it will unshare the printer.

 

We're working with our Managed Print Services provider to have a look into this problem, which we've narrowed down to Print Deploy.

 

Out of curiosity, did that service account you mentioned clone the print queues when you set up Print Deploy?

Posted

Interesting. The service account was used to login to an end user desktop at the time that queued unshared. The end user desktop had the print deploy client on it.

 

I used domain admin to replicate the drivers so I can confirm the service account that unshared the driver didn't do this. It was used to increment papercut install from version 18 to version 22 of the install.

Posted
Interesting. The service account was used to login to an end user desktop at the time that queued unshared. The end user desktop had the print deploy client on it.

 

I used domain admin to replicate the drivers so I can confirm the service account that unshared the driver didn't do this. It was used to increment papercut install from version 18 to version 22 of the install.

 

Interesting! There is definitely an issue with Print Deploy and some accounts randomly unsharing the printers assigned to Print Deploy client. Maybe if you log a ticket with Papercut, if enough of us do it they might twig there is more of an issue.

Posted
Interesting! There is definitely an issue with Print Deploy and some accounts randomly unsharing the printers assigned to Print Deploy client. Maybe if you log a ticket with Papercut, if enough of us do it they might twig there is more of an issue.

 

Ive logged a call with papercut, they have initially said this is a microsoft issue. Im not convinced as the issue began when we started using papercut print deploy

Posted
Ive logged a call with papercut, they have initially said this is a microsoft issue. Im not convinced as the issue began when we started using papercut print deploy

 

I think the more of us that log this issue, they might twig that its an issue!

  • Thanks 1
Posted
I think the more of us that log this issue, they might twig that its an issue!

 

Just want to say, once again, big thank you to EduGeek.

First time, thought: service hasn't started properly after an update.

Third time, thought: have we got malware we don't know about?

Fifth time, thought: someone's going to have an idea.

 

Print Deploy has recently been installed here too and that's when we started having our main virtual print queue just unshare itself.

Bizarrely we have another virtual print queue that remains unaffected.

Thank you for pointing us at the Operational Logs - we'll review and submit the issue to Papercut.

Posted
Just want to say, once again, big thank you to EduGeek.

First time, thought: service hasn't started properly after an update.

Third time, thought: have we got malware we don't know about?

Fifth time, thought: someone's going to have an idea.

 

Print Deploy has recently been installed here too and that's when we started having our main virtual print queue just unshare itself.

Bizarrely we have another virtual print queue that remains unaffected.

Thank you for pointing us at the Operational Logs - we'll review and submit the issue to Papercut.

 

Edugeek is often a very useful place!! Sometimes just needs a fresh pair of eyes!

 

I found that a user account in the Operational Logs of the Print Server, when that account logs to a workstation with Print Deploy installed it will Unshare whatever Print Queues are deployed via Print Deploy.

  • 2 weeks later...
Posted

OK, so apparently the person is me. We have a Sys-admin account we use for admin stuff on stations and I logged onto a PC with Print Deploy Client, whereupon the account unshared the printer from the server.

It doesn't do it all the time. How do I prevent it?

Do I just submit this to Papercut?

J

Posted
OK, so apparently the person is me. We have a Sys-admin account we use for admin stuff on stations and I logged onto a PC with Print Deploy Client, whereupon the account unshared the printer from the server.

It doesn't do it all the time. How do I prevent it?

Do I just submit this to Papercut?

J

We submitted a ticket, but they insisted on needing logs, and I haven't been able to reproduce the issue since. Hopefully the more people report this, the more likely they are to take it seriously.

 

It may well be a Windows bug, but I think PaperCut have to be the people to determine that, and I'm certain they've got a red phone with "Microsoft" written on it somewhere.

Posted
OK, so apparently the person is me. We have a Sys-admin account we use for admin stuff on stations and I logged onto a PC with Print Deploy Client, whereupon the account unshared the printer from the server.

It doesn't do it all the time. How do I prevent it?

Do I just submit this to Papercut?

J

 

Welcome to the club. So far the only sure fire way of stopping this is not to use the affected account. I logged it with papercut and even directed them to this tread to show its isn't only me. And there is a pattern of involvement with the papercut print deploy client. I was told the client had no ability to do this and it's a Microsoft problem. The ticket was marked as resolved and closed, not great service from papercut. I think my next step is to just erases the account and recreated it with a new SID. Luckily for me it's a service account that does it so we rarely use it on endpoints and isn't federated with Any mailboxes etc.

Posted
Welcome to the club. So far the only sure fire way of stopping this is not to use the affected account. I logged it with papercut and even directed them to this tread to show its isn't only me. And there is a pattern of involvement with the papercut print deploy client. I was told the client had no ability to do this and it's a Microsoft problem. The ticket was marked as resolved and closed, not great service from papercut. I think my next step is to just erases the account and recreated it with a new SID. Luckily for me it's a service account that does it so we rarely use it on endpoints and isn't federated with Any mailboxes etc.

 

You're lucky! Its my account that does the unsharing! Which isn't the end of the world...but have to remember to not login anywhere myself in school! I'd just like an acknowledgment from Papercut thats its an issue.

Posted
My colleague was the one affected for a while, and what we did was put a deny permission on the printer share for their user, and that "resolved" the issue for the time being.
Posted

I've not looked into Print Deploy in much detail, however I got both strong application repackaging vibes, which many of us may have forgotten (or never needed to learn in the first place), and woah! old-school (circa 2000) Windows Printer behaviours.

 

What I suspect is happening is that a during the printer capture process the offending account is interacting with the computer on which the printers are being packaged. This account probably has "manage this printer" rights on the printer object on the server, and is somehow tattooed into the deployment package.

 

Then during the deployment phase on a target workstation, the local printer object (settings and drivers etc) are deployed, there is some back and forth of settings (old-school: settings changes to a local instance of a server-shared-printer used to (sometimes?) write those settings back to the server) and since the deploying printer on the local machine is set "not shared" it writes that back to the server!

 

 

 

It has been years since I last saw client side changes writing back to the server - I'd assumed this behaviour was blocked. I know that the windows team are working hard to rebuild the print system, perhaps they have accidentally re-introduced the code path where this sort of thing can happen?

 

It may be that the offending account is not involved in the initial printer capture process - It might just be enough that the user has manage this printer rights on the server instance. It may also be that due to a regression this permission isn't even required!

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...