if I am using the following command command msg * /server:127.0.0.1 Hello world
then it opens pop box and displays Hello world
If I use the similar way to send a message to remote system
msg * /server:192.168.1.56 Hello world then it shows
Error 5 getting session names
whats the reason behind and how to send message to remote machine
remote os can either be windows 7 or windows 8.
Not since Windows XP. It's a security flaw.
msg send messages to terminal sessions on terminal server. Workstations are limited terminal servers, limited to one interactive user, so msg works on local computers.
Anything you can do remotely is always invisible to the user on the remote computer.
You can send a program to display a message using psexec by MS though, its not part of windows. http://technet.microsoft.com/en-us/sysinternals/bb545027.aspx
It may be possible to do it and the method you described should work.
I recently attempted to do this exact operation but I was blocked because if user rights on the PC's and the only way to make this function available was to edit the reg. You will continue to get that error until the Reg on both computers has been edited to allow the messages. Now if you are not on your own computer and you do have system administrators they could have blocked these functions for security purposes. If you want to attempt to edit the registry to allow you to do this you need to follow these instructions
Open the Registry Editor ( regedit.exe ).
In the left panel, locate and then click on the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
In the right panel, find the key AllowRemoteRPC and be sure the value of the key is 1. If the value is not 1, change it to 1.
Close Registry Editor and restart your computer.
Run MSG.EXE command in the elevated CMD window. Launch it when you hold Ctrl+Shift keys to enter elevated mode.
http://www.cezeo.com/tips-and-tricks/msg-command/
If you run into admin rights errors you will either need to contact the server admins or you will need to find a different way to talk to people in your office :P I recommend gmails messaging system for that. You can log into mail.google.com then click their email address on the bottom left and send them instant messages. As long as they have google up as well or set up email notifications to their phone they can communicate back with you.
Related
My solution has 2-machines where one is customer facing and the other is used by store personnel; in some situations when store personnel want to take control of the customer facing system we use UltraVNC to remote into it, push our application to a 2nd virtual display and put a PLEASE WAIT screen to the customer!
With Windows10 the concept of a virtual display is no longer possible so our remote view via UltraVNC lands on the primary display which means that the customer can SEE what the store personnel are doing and can also interact/interfere with it.... and this is my struggle today!
We found with UltraVNC we can "display user input" which works with keyboard/mouse but doesn't support blocking TOUCH input (we use a touchscreen) and there seems to be no way to put a PLEASE WAIT only to disable the screen (goes black - which has customers asking if the program crashed).
So opening this up to the general public to see if anyone has experience either with UltraVNC or has some completely different proposal for me to consider! I am open to all suggestions!
You rely on windows solution, On linux there is a dbus messaging system , I don't know if there is a similar messaging system in windows.
You may have a powershell script that unplugs the display or the touchscreen input.
and send a toast message to user.
https://gist.github.com/atao/12b5857d388068bab134d5f9c36241b1
Trying Windows Notification Service on the windows 10 desktop.
This line gets 0x880403E8 on "Local Machine" but works perfectly on "mobile emulator".
var channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
Turning off windows firewall didn't have any affect. What could be the reason?
I cannot reproduce your issue when calling CreatePushNotificationChannelForApplicationAsync to create a channel on my local machine which OS version is build 14393.
You are getting the Ox880403E8 error because the device is not connected to WNS server. There are a number of connectivity failures which get lumped together under the same error message. While you have internet connectivity in general, for some reason you weren't able to get to the channel server. So please make sure the device connected to the internet. If you're developing in an enterprise make sure they're not blocking outbound connections. More details please reference this thread.
More detail about WNS please reference this article.
Please see this screenshot:
As you can see there is several 'lines' around my application Background, this when i connect to the machine that running my application using Remote Desktop or Radmin.
This is when i am running my application on my local machine:
Any suggestions how to avoid this behavior ?
it is just remote access when connecting to a machine via remote access it doesn't give you the best picture. You could probably change the colour inside remote desktop settings it might give you a better picture but thats just the down side of using remote access
You need to configure the maximum color depth for a remote session, if the RDP session is hosted on a server. See the following article: https://technet.microsoft.com/en-us/library/cc772048.aspx
You also need to verify that Remote Desktop Connection options for Display have the Highest Quality (32 bit) color depth setting.
Also, The experience tab could be detecting a slow connection, and downgrading the quality. You can explicitly set the connection type to limit this behavior.
I am working on a line-oriented telnet server, not a client.
Currently, to set up the connection, I am using:
IAC DONT ECHO
IAC DONT SURPRESS-GO-AHEAD
IAC DO LINEMODE
IAC DO NAWS
Currently, the server only handles IAC AYT, and NAWS-related stuff. Anything else is rejected, like so:
IAC DONT <OPTION>
However, the server still gets characters one-at-a-time.
According to here, ECHO and SGA (at the same time) enable character-at-a-time mode. However, I have both disabled.
How can I make the client send data one line at a time?
I am using the telnet from GNU inetutils to test this.
This question's title is similar but, contrary to its title, concerns writing a telnet client.
I just checked my old telnet server source and I send WILL and WONT from the server side. I handled DO and DONT from the client.
Are you actually trying to code a true telnet server, or just a server that is compatible with telnet that does sends data a line at a time (like a text based chat or game server)? If the latter, you can do away with most of your options because in my experience, telnet clients default to line at a time.
For my game server (MUD++) all I ever did in standard game play mode was to disable / enable echo during password state in login, or kick into character mode and start a pseudo tty when the user invoked the PICO editor.
UPDATE: If you plan to seriously write a telnet server or any other network software, I really like the classic W. Richard Stevens series. TCP/IP Illustrated Volume 1, The Protocols covers telnet in a practical sense, and coupled with the RFCs like 1184 (if I recall) you'll have everything you need.
I have an application which injects keystrokes into applications via SendKeys.
Unfortunately, the application will not work when I am running it via Remote Desktop
because of the well known issue that SendKeys doesn't work with Remote Desktop.
Has anyone solved this issue before, or have any good suggestions on how to resolve it?
SendKeys is not a good fit mainly due to:
It can only send keys to active/focused application, which is never guaranteed to work because the the active application can change between the time the keys are actually sent.
RDP and many other libraries (e.g., DirectX) block them mainly for security reasons.
Better alternatives:
Use SendMessage or SendInput for simple needs
Some good examples of how to use SendMessage can be found:
Send strings to another application by using Windows messages
SendMessage via pInvoke
How To Send Keystrokes To Extern Win Application
For more elaborate needs, it is recommended to use WCF
To get you started, read this Basic Tutorial that talks about Inter Process Communication
Sample code using SendMessage:
HWND hwndNotepad = FindWindow(_T("Notepad"), NULL);
HWND hwndEdit = FindWindowEx(hwndNotepad, NULL, _T("Edit"), NULL);
SendMessage(hwndEdit, WM_SETTEXT, NULL, (LPARAM)_T("hello"));
In my case I was successfully using WinAPI's SendInput with hardware scan codes. It seems like SendKeys maps chars to scan codes incorrectly.
You can workaround RDP issue by having desktop always logged in before use (or configured for auto-login # every boot).
And even with the auto-login, if you ever need remote desktop access to run automation, or manage system, etc., the preferred method is using VNC for remote access rather than RDP. Reason is VNC is cross platform and you won't run into this RDP issue. VNC works like a relay of your actual desktop (RDP console session 0 or the "head" of the machine), the disadvantage being one remote session at a time only (or you all share the same desktop + keyboard + mouse). VNC will work for virtual machines too. Use VNC instead of RDP or local (RDP) access from the (VMWare/Hyper-V/Xen) virtual machine manager software.
The only thing to watch out for with VNC still is that the desktop not be configured to auto-lock on idle or screensaver, that may also stop send keys and GUI automation from running, so be sure to disable that. Screensaver & monitor power save is ok, just no auto-lock & password protect.
NOTE: I'm not sure, but believe since VNC relays the desktop "as is", it is the same as executing locally from the app/system's point of view, so it should in theory also be able to fool the system/app that doesn't allow SendKeys via RDP. I've had no issues using this VNC method for AutoIt + SendKeys, whether I was actively connected via VNC, or disconnected (sendkeys/automation still continues to work after disconnect because on the actual desktop, it's still logged in, just that VNC not active).
In my case I was using sendkeys as part of test automation. It would not work from my build machine, where the build agent runs through remote desktop protocol. I'm not happy about it but I was able to skip that test as part of my automated builds.
Using Win32 calls to send window messages might work, if I have time I may try that someday.
Anyhow, here is the check to see if the current code is running in a remote desktop session:
System.Environment.GetEnvironmentVariable("SESSIONNAME").StartsWith("RDP-")