In order to use command line arguments, you must enclose the entire command in double quotes. Of course, many commands require that you provide command line arguments. You’ll need to ask the user to enter it for you, but at that point, you can work with the application precisely as the user works with it. At this point, the RunAs command will ask for the user’s password. For example, if you want to see how Notepad works for user John, you’d type RunAs /User:John Notepad and press Enter. To gain a basic appreciation of how the user views things, simply type RunAs /User: UserName Command and press Enter (where UserName is the user’s fully qualified logon name including domain and Command is the command you wish to test). You can see some basic coverage of this command on page 480 of Windows Command-Line Administration Instant Reference. In addition, this approach uses the RunAs command defaults, such as loading the user’s profile, which could cause the application to react differently than it does on the user’s system because it can’t find the resources it needs on your system.Ī more practical approach is to use the RunAs command directly to get the job done. However, the GUI has limitations, including an inability to use this approach for batch testing of an application. In fact, if you Shift+Right Click the application, you’ll see an entry for Run As A Different User on the context menu that allows you to start the application as any user on the system.
Most knowledgeable users know that you can simulate an administrator by right clicking the application and choosing Run As Administrator from the context menu.
Anyone can run an application at the administrator level with good success, but the user level is another story because the user might not have access to resources or rights to perform tasks correctly. Of course, this means seeing what the user sees.
It doesn’t matter what your forte might be (programmer, administrator, DBA, manager, or the like), getting the user view of things is essential or your efforts are doomed to failure. One of the problems with writing applications, administering any network, or understanding system issues is to ensure that you see things from the user’s perspective.
0 kommentar(er)
