|
Dave Kreskowiak wrote: Nope. You're running a command line app and the command prompt is telling you
who it's running as. If the user isn't what you expected it to be, well, that's
a problem in your code, not the test. This is telling you who the SC command is
running as. If that account doesn't have the appropriate permissions to the
target machine to start and stop services, it's going to fail.
Ok Mr. Smarty Pants  (j/k)... explain this one... I have just proved again that the impersonation code I am using is working:
using (new Impersonator(_strDomain, _strUsername, _strPassword))
{
System.Diagnostics.Debug.WriteLine(System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString());
System.Diagnostics.Process.Start("CMD", "/K WHOAMI");
}
I have just conducted two tests there... your CMD /K WHOAMI (which returns the wrong non-impersonated logged on user) and WindowsIdentity.GetCurrent() (which CORRECTLY returns the impersonated user!)
I am running on Windows 7 as an admin on my box (but not the remote box), UAC is disabled. So that block of code *is* running as the impersonated user, but Process.Start() seems to be running as non impersonated currently logged on user.
|
|
|
|
|
If you're going to use Process.Start, the ONLY thing that matters is what the CMD window is using.
The impersonation code that you're using does NOT affect the process you launch with Start. The only thing that changes that is using the Start overload that accepts a username and password.
I'm not the "Smarty Pants" here. The CMD prompt is telling you exactly what you need to know and you're ignoring it! That little window is telling you that using the Impersonator class has no effect on which account another process is launched as.
|
|
|
|
|
Dave Kreskowiak wrote: The impersonation code that you're using does NOT affect the process you launch
with Start. The only thing that changes that is using the Start overload that
accepts a username and password.
I'm not the "Smarty Pants" here.
The CMD prompt is telling you exactly what you need to know and you're ignoring
it! That little window is telling you that using the Impersonator class has no
effect on which account another process is launched as.
Ok, that makes sense. I guess the methods that ARE working under impersonation are File.Copy() and ServiceController which will run under impersonation.
Kind of weird though, I'm launching PSKILL using Process.Start() and that is working, but I'm using both the impersonation and the built in username & password thing... seems like that one required both... if I just had one or the other, it wouldn't work.
Regardless of all that, obviously, yeah, I gotta get Start() working with the username & password... this is my code for that:
System.Security.SecureString ss = new System.Security.SecureString();
foreach (char ch in _strPassword)
ss.AppendChar(ch);
System.Diagnostics.ProcessStartInfo si = new System.Diagnostics.ProcessStartInfo("cmd.exe");
si.UseShellExecute = false;
si.RedirectStandardInput = true;
si.RedirectStandardError = true;
si.RedirectStandardOutput = true;
si.UserName = _strUsername;
si.Password = ss;
si.Domain = "xxx"; // obviously censored for the forums
si.Arguments = "/K";
System.Diagnostics.Process.Start(si);
This gets a:
An unhandled exception of type 'System.ComponentModel.Win32Exception' occurred in System.dll
Additional information: Access is denied
|
|
|
|
|
HOLY BAJESUS... 3 or 4 days on this and finally solved the problem... changed so many things not sure which one in particular did it... but I think the main culprit was moving the function call outside of the using (Impresonator) block... the two interfere for some reason even though they use the same exact creds.
|
|
|
|
|
Your command string evaluates as sc\\strMachine config. You need at least one space between sc and \\.
Use the best guess
|
|
|
|
|
It does? How do you figure?
System.Diagnostics.Process.Start("sc", "\\\\" + strMachine + " config \"<the service name>\" start= demand");
The first param is "sc" and then there's a comma there and the second param is the argument string.
|
|
|
|
|
SledgeHammer01 wrote: How do you figure?
Easy: epic fail on my part.
However, I do agree with Dave K's suggestion that you build your parameters into a variable so you can see exactly what is being sent to the command processor.
Use the best guess
|
|
|
|
|
There is no overload of Process.Start that allows the executable filename and arguments to be combined into one string. I suspect that you'll find that the documentation[^] will be a great help in your endeavours.
[EDIT] Sorry ignore this, I've just looked at your code again and see that I can't read!
Alan.
|
|
|
|
|
It does? How do you figure?
System.Diagnostics.Process.Start("sc", "\\\\" + strMachine + " config \"<the service="" name="">\" start= demand");
The first param is "sc" and then there's a comma there and the second param is the argument string.
|
|
|
|
|
Sorry for the late response. I think there an old carpenter's adage which goes something like "measure twice and cut once". As I hadn't spotted that comma I guess I should have read twice and then not answered at all!
Alan.
|
|
|
|
|
The applications I write typically involve a lot of data entry, for use in a warehouse/manufacturing environment. Sometimes there can be many different fields, sometimes not so much. But I've always found it a bit tedious and time consuming to restore the UI to its initial state when the user saves an entry, for example.
I mean, a form could have buttons that are disabled initially, a few entry fields that are disabled at first waiting for other input, several input fields that need to be cleared, etc. What is the best method to go about resetting a form once the user is done? I've always just used "thisField.Enabled = false;" and "thatField.Text = string.Empty;" and so on. But is there a more efficient method for achieving this?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Replacing the form with a new instance would be a shortcut to "restore" the initial state.
|
|
|
|
|
I could have clarified "form", since I'm referring to WinForms applications. "Form" in this context was actually meant as an input form, not the window itself. But I think I can follow that same concept. I'll give it a try.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Oh duh... OK...
You can reset a form...
myForm.Controls.Clear();
myForm.InitializeComponent();
|
|
|
|
|
Thank you, I'll give this a try. Very simple and seems like it should do exactly what I need. 
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
The only problem with doing that is that if your form code maintains a state it's not going to get reset. It'll only destroy and recreate the controls to however you had them set in the Form Designer and property settings.
|
|
|
|
|
But isn't that what he wants? Instead of "clearing" everything, which sets textboxes to empty string and whatnot, I thought he wants the "default" values from the form designer to show up - otherwise, yeah, you only need to Form.Controls.Clear() and call it good.
|
|
|
|
|
I don't let the controls determine the status of any state machine I've got behind the forms. The state machine determines the state of the controls and the controls reflect that.
I know there are plenty of cases where the app or form is so simple that there is no state machine behind it, but there are too many noobs out there who rely on the controls to "store" data and determine the state of a form or app based on, say, the text of a button, or if it's enabled or not.
That's not the proper way to do it.
|
|
|
|
|
Yeah definitely incorrect designs would make it more tricky, but I get the impression this particular form doesn't have any initial state other than what was set in the designer...
|
|
|
|
|
While it's a good idea  , I'd still call it a hack, unless xml-documentation is included with some explanation like Dave posted. Private members would not be reset, and the "OnCreate" event wouldn't fire on it's own. It might contain some "form magic" for setting the form up as well.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Well, I used the "hack" and it works just fine. I'm still going to experiment with other options based on everyone's input. But for my purposes, the "hack" gets the job done for now at least. 
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
I just re-load the page...
If you're currently on "MyPage.aspx" this will reset it.
Response.Redirect("MyPage.aspx", true);
|
|
|
|
|
Matt U. wrote: But I've always found it a bit tedious and time consuming to restore the UI to its initial state when the user saves an entry, for example.
Form.Controls.Clear();
InitializeComponent();
Alternatively, loop all controls using reflection (no, it ain't that slow, just a bit of an exercise to get recursion working) and clear them.
How do your edit-forms look like? Mine could be explained as a PropertyGrid on a dialog-form. It has an extra button called "reset", which just reloads a cloned object into the propertygrid.
It's not a real property-grid anymore; it's a custom control that behaves in a similar way (in code), but that renders a more 'traditional' winform.
I choose this architecture out of convenience; a single modification in the object, and it's pushed to a Memento-pattern (undo/redo stack). When closing, the content of both get serialized and saved. When loaded, both are restored - it makes users happy when they find out that they can "undo" yesterday's changes, even if the PC was turned of in the mean time.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: they can "undo" yesterday's changes
THAT, is hard freeking core, dude. I like it
As noted before though, I think the only way to make it behave like a 'new' form is to have it be a new form... but if it's your main form or something, that might require hacking program.cs.
|
|
|
|
|
Jasmine2501 wrote: I like it
Tx
Can be a bit confusing though; most users expect an empty undo/redo-list when they launch an application.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
