Can I enable / Disable an Azure Service Bus Topic using Powershell - powershell

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.

Related

How to trigger RegenerateUserEnvironment forcibly

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

Azure DevOps - Can we reuse the value of a key in the same variable group?

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

Reading an SB-Messaging Send Port properties using the Microsoft.BizTalk.ExplorerOM makes a breaking change

I am working on a PowerShell script making use of the Microsoft.BizTalk.ExplorerOM to dynamically update the SB-Messaging SAS key for BizTalk Receive Locations and Send Ports. This is to enable us to roll the SAS keys for our Service Bus queues, and update BizTalk with the new keys as painlessly as possible.
I have this working correctly for Receive Locations, but Send Ports are giving me a different issue.
As soon as I read the PrimaryTransport properties of the Send Port, it seems that some change is made under the covers, that then prevents SaveChanges from working, instead throwing an "Invalid or malformed XML data exception".
This is compared to the the ReceiveLocation, where I can read any of its properties, and then SaveChanges successfully.
Note that in both of this cases, no changes have been made by me. I am simply doing a Read, and then a Save.
Can anyone offer any advice as to what could be causing the issue, and any possible solutions to try?
Had this very same issue, when using Powershell to replace values in ServiceBus ReceiveLocations & SendPorts.
The problem is with the none valid xml symbols in the TransportTypeData, which are converted when the script reads them out in the PS cmd.
All none valid xml symbols (such as the one occuring for Namespace value, ) need to be converted to amp, and if I'm not mistaken even double amp:ed.
Here's an example article showing examples on what I mean by "double amp:ed":
How do I escape ampersands in XML so they are rendered as entities in HTML?
Hope this make sense, and if not, then let me know and I'll give it another go.
Just tried doing this from C#, seems to work ok:
var root = new Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer() { ConnectionString = "Data Source=(local);Initial Catalog=BizTalkMgmtDb;Integrated Security=SSPI;" };
var sendPort = root.SendPorts["xxxx.ServiceBusQueue"];
System.Diagnostics.Trace.TraceInformation(sendPort.PrimaryTransport.TransportTypeData);
sendPort .PrimaryTransport.TransportTypeData = sendPort.PrimaryTransport.TransportTypeData.Replace("RootManageSharedAccessKey", "MySharedAccessKey");
root.SaveChanges();

CloudWatch Alarm via PowerShell - issue with InstanceName

I want to create CloudWatch alarms automatically on instance launch (via AutoScaling, CLI or whatever).
My instances are running Windows, so I created task in Task Scheduler which executes PowerShell script.
This script uses Write-CWMetricAlarm cmdlet to create CloudWatch Alarms - http://prntscr.com/e6xptj
It works good for custom Metrics like Windows/Default , but for AWS/EC2 Instance­Name is required as well - http://prntscr.com/e6xq18
But there's no Dimension for Instance­Name - http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ec2-metricscollected.html
.. as well as no suitable parameter for Write-CWMetricAlarm Cmdlet - http://docs.aws.amazon.com/powershell/latest/reference/Index.html
So any ideas about how this issue can be solved?
Thanks in advance!
Instance names are actually just tags (with key "Name") and the console gives them special treatment to make them appear as a first-class item. They also do not need to be unique, so using 'name' wouldn't enable CloudWatch to distinguish between different instances, making things confusing from an alarm perspective.
I think therefore that you need to be using the instance id value. In your script I notice you're using Invoke-Restmethod to obtain it - you might be interested to know you can also get this value using a cmdlet:
Get-EC2InstanceMetadata -Category InstanceId

Create event log entry with powershell and fill in user

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.