I'm deploying a resource group to Azure consisting of a VM, a network, an Automation Account with some runbooks, among other things, using a JSON Template.
I'm getting the following errors,
New-AzureRmResourceGroupDeployment : 4:49:23 PM - Resource
Microsoft.Automation/automationAccounts/runbooks
'DeployAutomationName/AzureClassicAutomationTutorial' failed with
message '{ "code": "BadRequest", "message":
"{\"Message\":\"Invalid argument specified. Argument contentLink
cannot be null.\"}"
As well as:
New-AzureRmResourceGroupDeployment : 4:49:23 PM - Resource
Microsoft.Automation/automationAccounts/modules
'DeployAutomationName/Microsoft.WSMan.Management' failed with message
'{ "code": "BadRequest", "message": "{\"Message\":\"The
ContentLink property must be supplied in PUT or re-PUT operations.\"}"
}'
These two errors repeat for all sorts of different "Assets" ( I think that's the term) of my automation account. So for modules, runbooks, certificates, and connections.
What is a contenLink, and how can I make sure it's not Null? "ContentLink" apppears nowhere in my template, nor can I found any explanation on the internet of what exactly a contentLink is, besides this. Furthermore, I'm assuming that "PUT" or "re-PUT" is part of the rest API that delivers the template, and I have no direct control over this process either. Of what use is an error message that describes problems I have no direct control over?
This problem is synonymous with many of the difficulties I've had succesfully troubleshooting Azure templates: the error messages I get seem to be describing Azure Internals that I have no understanding of nor access too. How can I troubleshoot or debug when I don't have access to the code that is actually throwing these exception, nor the explanation of what this exception means?
Thanks! Here is my template , I would have only copied the relevant text, but I haven't a clue what is relevant and what's not:
Ok, so after poking a little bit, it looks like you are missing the runbook content (the script itself). so your runbook resource should look like this:
{
"type": "Microsoft.Automation/automationAccounts/runbooks",
"name": "[parameters('runbooks_AzureAutomationTutorial_name')]",
"apiVersion": "2015-10-31",
"location": "eastus2",
"properties": {
"runbookType": "GraphPowerShell",
"logVerbose": false,
"logProgress": false,
"publishContentLink": {
"uri": "[variables('scriptUri')]",
"version": "1.0.0.0"
}
},
"resources": [],
"dependsOn": [
"[resourceId('Microsoft.Automation/automationAccounts', parameters('automationAccounts_deployautomation_name_1'))]"
]
},
and the variable:
"variables": {
"scriptUri": "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-automation-runbook-getvms/Runbooks/Get-AzureVMTutorial.ps1",
},
I can't test the whole template, as I don't have base64 values, but I believe this should solve your issue. There might be another one after this, thou ;) who knows.
Reference data: https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-automation-runbook-getvms/azuredeploy.json
Also, you can just remove modules from the template, as they are not required, they are all the default ones, but for them the idea is the same, you are deploying the module without giving the module data.
And you might be missing other mandatory properties here and there, looks like Automation Script doesn't really work well with Azure Automation yet. You might want to resort to Powershell to provision Automation Account, as that works perfectly fine.
P.S. I have no idea what the content of the graphical runbook looks like. But i'd guess, you can export it and upload to github, and it would work.
Related
I'm trying to automatically create review apps as part of my pipeline and testing procedure when pull requests are created on the corresponding GitHub repository. When the PR is created, it appears as a review app, but doesn't actually get created.
In the DevTools console, a 404 error is there about the review-app-config. I'm not sure if this is directly related, as I've successfully created a review app on a different pipeline (with a different owner) with the same error.
This 404 error changes between the file not being available at all, or that it's returning an error. When it's the latter, the file contains the following:
{"id":"missing_version","error":"Please specify a version along with Heroku's API MIME type. For example, `Accept: application/vnd.heroku+json; version=3`.\n"}
I'm creating and managing all of the apps/pipelines with the GUI on dashboard.heroku.com. The version accept header appears to be needed for the Heroku API but I've no idea how to implement it. Any help would be greatly appreciated!
Firstly check that your app.json file is valid json. If it isn't then that will cause the deployment to fall over.
Secondly check if you have any scripts in the app.json key. If you have any here and they are incorrect then this will also cause it to hand and fall over with no warning displayed.
{
"name": "App name",
"scripts": {
"deploy": "command that won't work!!"
},
...
}
You many not need any scripts in here so it can also be empty!
{
"name": "App name",
"scripts": {},
...
}
I have a problem regarding Azure DevOps and release management. First a little background - we use visualstudio.com along with build agents, release agents (running on different environment VMs) to manage our CI, builds, and releases. I am trying to troubleshoot logging on my non-development servers and have traced the problem back to missing elements in my appsettings.json file. When I log into my production VMs and look at the appsetings.json file, I found that my Logging section looked like this:
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Information"
}
},
While within my appsettings.json file within my build artifacts (the website .zip file) looks like this:
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
},
My logging issues are fixed when I go on the server and change the appsettings.json Logging section to match what is should be according to the appsettings in the build .zip.
My question is - what is it within the Azure DevOps release pipeline (formerly VSTS) that is changing the appsettings.json Logging section? I have verified that my release definition has no variable substitutions for the logging section.
This looks very much like your build is taking the wrong sources. Is it possible that the wrong appsettings.json that you're seeing reflects an outdated version? I don't know why this happens, but I've seen this a couple of times in the past both with Git and TFVC.
If this is the issue, then cleanup your agent working folders or select (once or permanantly) cleanup in the build definition:
Found the problem (and its a silly one). The problem ended being multiple declarations of the Logging section in the appsettings.json file. The declaration at the bottom of the file has:
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Information"
}
},
which would match whats getting deployed.
I want to extend a custom OData service created in a S/4HANA system. I added a Cloud Connector to my machine, but I don't know how to go from there. The idea is that I want people to access the service from SCP and that I don't need multiple accounts accessing the service on the S/4 system, but just the one coming from SCP. Any ideas?
Ok I feel silly doing this but it seems to work. My test is actually inconclusive because I don't have a cloud connector handy, but it works proxy-ing google.
I'm still thinking about how to make it publicly accessible. There might be people with better answers than this.
create the cloud connector destination.
make a new folder in webide
create file neo-app.json.
content:
{
"routes": [{
"path": "/google",
"target": {
"type": "destination",
"name": "google"
},
"description": "google"
}],
"sendWelcomeFileRedirect": false
}
path is the proxy in your app, so myapp.scp-account/google here. the target name is your destination. I called it just google, you'll put your cloud connector destination.
Deploy.
My test app with destination google going to https://www.google.com came out looking like this. Paths are relative so it doesn't work but google seems proxied.
You'll still have to authenticate etc.
I have an Azure Dev Test Lab that I am deploying to Azure via Power Shell. I am able to deploy the ARM templates and join to the test domain (not Azure AD) with no issues. The next step I would like to do is to set the IP to static. I can think of 3 ways to possibly do this. Either figure out the IP structure beforehand and deploy it with those settings. Let the DHCP assign the settings and try to problematically set them from Dynamic to Static using Powershell DSC. Or some type of preferred lease from the DHCP. These labs are meant to be stood up and torn down ad hoc. The IPs are internal and not Public. It is possible for me to know the IPs before hand. Could someone make a recommendation on what would make the most sense to pursue?
Well, there are several ways of looking at it, first of all, you can define ip at deployment time, by setting it to static, instead of dynamic:
{
"name": "xxx",
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2016-10-01",
"location": "loc",
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Static",
"privateIPAddress": "ipgoeshere",
"subnet": {
"id": "subnetgoeshere"
}
}
}
]
}
but this method is only valid if you know the available IP addresses beforehand and you will have to look those up and pass to the template.
Another way of doing this is créating NIC as dynamic, getting its IP address and setting it to static. All can be done with an ARM Template. The example is a bit too much to paste here, you can check it here. look for deployments called: "[concat(variables('vmNamePrefix'),'setStaticIp')]", and "[concat(variables('vmNamePrefix'),copyIndex(1),'-primaryIp')]", and their corresponding templates: getip and setip
You can do pretty much the same with powershell, I dont have a script Handy, but the logic is the same, deploy > getip > setip
I'm trying to test a site out using the IBM Watson Natural Language Understanding service. I'm doing so using this tool (https://natural-language-understanding-demo.mybluemix.net/) and entering a URL from our site to test.
Using our production servers (https://www.knox.edu), I get the following error for every page of the site.
{code: 400, error: "attempt to fetch failed: :closed"}
Using a test server of the same site (https://cmstest.knox.edu/test), it all works fine though.
What would be causing the errors from our production server?
Thanks!
This error is typically caused by a site's robots.txt preventing the Watson NLU service from scraping the URL.
Check your robots.txt file to see if it's blocking user-agents (perhaps globally).
There's some additional info from a discussion of this error using the Python SDK here: https://github.com/watson-developer-cloud/python-sdk/issues/199
Looks like NLU has updated their crawling engine, the website you mentioned is crawlable from NLU now, when I ran categories call I am receiving the following output
{
"categories": [{
"score": 0.999469,
"label": "/education/graduate school/college"},{
"score": 0.497251,
"label": "/law, govt and politics/legal issues/legislation/tax laws},{
"score": 0.466882,
"label": "/travel/tourist destinations/africa"}]
}