Ax2009 printing from AOS - printing

How is it possible to hide printers that are locally installed on the AOS server for specific users for a AX client that is hosted using terminal services?
It still needs to be possible to print to the printers from the AOS while setting up print job settings in the code from AX client and all of the users, but certain users should not be able to see the printers, or a certain number of printers, in the print job settings dialog when it comes up.
Or, is it possible to define whether or not certain users have access to certain printers from the AOS?
Note: You can set in the client settings whether or not printers should be usable from the AOS, but if you are using terminal services for hosting the AX client, then all users are using the same configuration and therefore, if you want to set it so that one user can see the AOS printers, than all of the users are able to see the printers from the AOS. (Or I am mistaken here?)

It is not possible make user security on printer from AX.
It may be possible using Windows security, but it might backfire if AX can see the printer but not use it.

Related

MVC access client side printers

In my MVC5 intranet application, I need to give, for some users, the possibility to print badges. The special printers for the badges are installed in the user's PCs.
How can I access this printers?
I made some research on the web, and honestly I did not understand what is the state-of-the-art better solution (Silverlight, WCF service, ...).
if your are looking to change the default printer or print automatically to current printer it is not possible from a web browser for security reasons.
even if it is in an intranet

Sending Commands to a Remote Printer

I'm working on a web project in which I need to be able to communicate directly with my customer's printer. The customer uses my application through a browser, and would like to be able to click a button to print tickets uninterrupted, meaning there is no printer dialog popup from the browser. This requirement eliminates many traditional ways of sending information to the customer's printer, and because I want a solution that will work on any browser, solutions that use VBSCRIPT or other browser-dependent solutions will not work.
My initial solution for this problem was to create a Java applet that was loaded into the page dynamically when a "Print" button was clicked. However, browsers like Chrome and soon Firefox are removing support for NPAPI, which breaks my Java plugin.
The current solution I'm working on is to create a service in C# that the user installs locally on their machine, and then when the customer clicks the "Print" button, my server communicates with that service directly. This way I can bypass the browser restrictions, and the service running on the customer's machine will have full access to communicate with the target printer. The downside to this approach is that the user now has to install an additional bit of software on their machine, and for each machine they wish to access my application on and print from, that machine needs to have proper port-forwarding and firewall settings configured. I can make this work for my current customer, but with future customers it becomes a hassle. Furthermore, my new approach currently only supports Windows machines, and if future customers are using OS X or Linux, I will need to port the service.
Has anyone faced this problem before, or are there any ideas out there for how to communicate with a client's printer that is browser-independent?
There's no possible solution to this that both supports Chrome and doesn't require something to be installed on the machine; you can't run arbitrary code that interfaces with the OS from within Chrome. And the only way to interact with that other code besides a local web server would be Native Messaging in an extension, but that doesn't fulfill your cross-browser requirement.
you can't communication directly because of security. i also develop 1 application in c# for remotely printing.
there is one way if your client have remote printer then you can do this task easily make small app on server and integrate with all remote printer and you can execute printer command from server and print will comes from client printer

Power Query Windows authentication with Odata feed

I am currently trying to find a way for a customer to connect with Power Query (plugin for Excel) to access their published Odata-feed (which is hosted by Microsoft NAV 2013 R2).
For security reasons the NAV server is set to only accept Windows as an credential type. This means that the current user credentials on the client is passed on to the webservice.
The problem: The users of the system is often off site and working on another domain with a VPN connection to the NAV-environment. With that said Power Query does not pass the "correct" AD-information to the published Odata-feed which means that the user is not authorized.
I am looking for a way to change which AD-credentials that are sent thru Power Query and then to the Odata webservice.
The users have no problem typing in the webservice adress in a web browser and type in the Windows credentials when prompted and access the feed. But in Power Query there is no option for typing in custom Windows Credentials when refreshing the data.
I've tried with WebAPIKey and Basic authentication. But since the NAV-server/Webservice is set to only accept Windows authentication I'm in the dark..
Any thoughts?
I got this answer from Curt Hagenlocher (Moderator on Technet)
I'm afraid this isn't something we currently support, though we have
considered implementing it. We do loosely track feature requests and
use them to prioritize future work.
(https://social.technet.microsoft.com/Forums/en-US/03c529ba-5f20-4bc1-84de-35cc91e7c1a6/power-query-custom-windows-credentials-authentication-with-odata-feeds?forum=powerquery)

‘Allow service to interact with desktop’ option not available when configuring windows service with an account other than local system

Why the option ‘Allow service to interact with desktop’ is only available for Local System account and not for any other account while configuring a windows service from control panel? I want to configure the windows service so as to allow interaction with desktop irrespective of the account it is configured to run with. How to achieve it?
that is a good question! I have never seen an official explanation from Microsoft, but I would guess that the reason has to do with permissions and rights and not wanting to mislead users.
Not all users are created equal. Some do not have the rights to display a user interface on session 0, or interact fully with arbitrary programs (and resources) it is running alongside. Having those users able to show GUI elements from a service may lead to confusion. For example, if a user account having limited rights starts an instance of Windows Explorer as a service, that window may not be able to accept dropped files from a "regular" explorer started by the interactive user. This sort of thing may be very difficult to diagnose and explain!
Note that Windows can certainly do what you like and we code it all the time in our service applications (http://www.CoreTechnologies.com/). Windows is simply not making that option available to you for any arbitrary user.
Of course please please take a step back and beware changes in Vista. "Session 0 Isolation" is a game changer for interactive Windows Services!

How to prevent from changing a Windows Service Startup Type?

I created a Windows service and installed into users machine.
That windows service is very important and I do not want to user can change its startup type to "disable".
It seems "Plug and Play" service can disable the Startup drop-down listbox.
How can I make same behavior for my windows service?
I would imagine it has to do with setting the appropriate permissions on the registry key. But a user with sufficient permissions can do anything. If this is for a business application, I would try to stick to using group policy or user permissions. If this is for a commercial application then I would expect a lot of upset users and malware detection.

Resources