I'm currently having trouble applying logon script(powershell) on windows servers.
The logon script has the line to set user environment variables but the variables don't look like being applying immediately from the result of set command on command prompts.
I've been looking at the behavior through process monitor while logging on to the new session.
And finally I have found the newly created variables need to be associated with RegenerateUserEnvironment function on shell32.dll.
I'm able to look at the correct result of set command after RegenerateUserEnvironment is called.
So I was wondering whether we had a way to trigger RegenerateUserEnvironment function and it needs to be executed on powershell.
Can you shed some light on this?
Best Regards,
Haewon
Related
I have lots of URL values and their keys. But there is no way to batch import the variables and the "value" controls are also not text boxes in the Variables Group page to perform chrome browser extensions assisted find and replace.
If this is possible, what is the syntax to refer to the key?
As in, I have a variable App.URL : www.contoso.com.
I am using the key to substitute value in my next variable like this Login.URL : $(App.URL)\Login and this doesn't work.
GitHub link : https://github.com/MicrosoftDocs/vsts-docs/issues/3902#issuecomment-489694654
This isn't currently available, not sure if it will be. Can you create a task early in your pipeline that sets the variables you need in subsequent tasks/steps? This gives you more control as you can store the script along with your source. You could then use a pipeline variable for the environment you're in and let your script use that to set values appropriately.
See Set variables in scripts in the MS docs.
If it's not possible to re-architect your app to concatenate the url strings in the application, what the previous commenter said about creating a simple script to do that for you would be the way to go. Ie:
#!/bin/bash
#full login url
fullLoginUrl=$APP.URL\$LOGINSUFFIX
echo "##vso[task.setvariable variable=Login.URL]$fullLoginUrl
Otherwise, perhaps playing around with the run time vs compile time variables in YAML pipelines might be worth trying.
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#understand-variable-syntax
Run dick gives us the ability to define options to be entered by the its GUI, is there any capability to have job variable based on the input without the end user of the job seeing it?
E.g, if the the user choose the product and the environment and the product behind LB, I want to use a script internally to define new job variable and assign it the port number that could be used later on within the job steps.
Yes, there is.
You can add a new option whith Allowed Values set to Remote URL, then put the URL to your script which will return the actual value based on other options.
For exmaple
http://localhost/cgi-bin/getPort.py?environment=${option.environment.value}&product=${option.product.value}
Rundeck Manual option-model-provider
I have spent a couple of hours search for a solution to disable my Azure Service Bus Topics using Powershell.
The background for this is we want to force a manual failover to our other region.
Obviously I could click in the Portal:
but I want to have a script to do this.
Here is my current attempt:
Any help would be great.
Assuming you're sure your $topic contains the full description, modify the status parameter in the array and then splat it back using the UpdateTopic method. I'm afraid I can't test this at present.
$topic.Status = "Disabled"
$topicdesc = $NamespaceManager.UpdateTopic($topic)
I don't think you'll need to set the entity type for the Status, nor do you require semi-colons after each line of code in your loop.
References
PowerShell Service Bus creation sample script (which this appears to be based off): https://blogs.msdn.microsoft.com/paolos/2014/12/02/how-to-create-service-bus-queues-topics-and-subscriptions-using-a-powershell-script/
UpdateTopic method: https://msdn.microsoft.com/en-us/library/azure/microsoft.servicebus.namespacemanager.updatetopic.aspx
Additional note: please don't screenshot the code - paste it in. I'd rather copy-and-paste than type things out.
I would like to run a few NirCmds when running an application such that it will change the primary display to the extended monitor, run the app and then switch back when finished. Ideally I would like to create this as a context menu option. Since this is using multiple commands I thought of using the script functionality from nircmd such as:
script "$folder.desktop/testscript.ncl"
with the script containing the lines I needed:
setprimarydisplay(2)
exec max "???.exe"
waitprocess ???.exe setprimarydisplay(1)
However I am not sure how to pass the process name from the context menu into the script or if this is even possible. Does anyone know how to do this or am I approaching this the wrong way?
I have the process location from the context menu as %1, so the issue is really just passing this into the script. Something like:
script "$folder.desktop/testscript.ncl" -%1
I need to create entry to Windows Event Log (e.g. application log). I know how to do all the stuff beside filling in the user who performed the action.
Example:
I need to create a script, that writes some message into application log. I used this tutorial, which worked fine: http://blogs.technet.com/b/heyscriptingguy/archive/2013/06/20/how-to-use-powershell-to-write-to-event-logs.aspx
But I am not able to influence the "user". When adding entry in windows log, it always fills "User: N/A".
Any idea how to pass "user" argument to the "write-eventlog" cmdlet?
Thank you for your help.
Even though (as far as I'm aware) Write-EventLog does not provide an option to write directly to the "User" field, you have two workarounds:
Use built-in standalone exec "EventCreate.exe" (type in eventcreate /? to see the manual)
This one does support providing the username field. I'm not sure, but it may require a password for that user too.
Second workaround would be to pass $env:USERNAME to the "message" field of Write-EventLog. This way you will still obtain the environment's current user.
I hope that helped.