Are there any Azure Automation DSC gurus who can help with some guidance and know-how for pushing through a couple impasses I am currently encountering?
The task at hand is: Use Azure Automation Runbook to provision a VM. That VM should immediately be associated with a DSC configuration, which will adjust Windows features, settings, and install SQL Server according to a specific configuration. All tasks conducted need to be written in PowerShell and should require no manual input via Azure portal at any point.
At this time, the Runbook provisioning the VM is working perfectly. However, associating this new node with a DSC configuration is still a manual process, which also is working (with the exception of the next issue mentioned below). However, this process needs to be automated instead. How is this done? Via DSC resources as children of the VM resource in the ARM template?
Getting SQL Server installed is the next step. The xSQLServer DSC module seemed perfect for achieving this, but it currently has a bug in Azure Automation, which means that the xSQLServerSetup resource is not available, even when using older versions of xSQLServer. So, there appear to be two possible workarounds to this…
Workaround 1: Not use xSQLServer and just run a PS script that is local on the newly provisioned VM to install SQL Server using a command line installation using an INI file. The PS script to install SQL works, but only when run manually. When attempting to have DSC run this script, Azure is throwing an error that the script is not digitally signed. So, there appears to be a permissions scoping issue at play, and the DSC credential is not able to run the local PS script even though the local admin credential is being passed in. How does one get around this?
Workaround 2: Apparently, it is supposed to be possible to provision a VM, compile the DSC MOF local on that machine (with the full version of xSQLServer), and then push that registration back to Azure Automation. Though, it is unclear how exactly this would be done, as it appears to also require the execution of a local PS script, thus providing the same impasse as the first workaround. Is this perhaps via a Custom Script extension in the ARM template, or…?
I can see all of the parts in play, and I’ve found several helpful resources online that give breadcrumbs to the solution. But, the breadcrumbs are too far apart, and the proper way of wiring everything together is proving to be elusive. So, I’m here humbly asking for help and guidance in getting this worked out.
Any help would be greatly appreciated.
Thanks!
First of all that's a lot of questions instead of 1.
unless this is some kind of homework - there is no point in installing sql on a vm, there are a lot of vm + sql images in Azure and it would take 5 minutes instead of 60 to provision such a vm.
When attempting to have DSC run this script, Azure is throwing an error that the script is not digitally signed. - this means your script is not signed (not related to rights\permissions), look for execution policy, you need to set it to unrestricted before running your script (but you don't need to, because of the first point).
you compile mof or upload it and then you can "tie" a vm to that mof, it can be automated with powershell (both parts), there are a lot of guides on how to do that. Like this
As a general rule, use arm template to do the whole thing, again, there are lots of examples on how to achieve that (just browse this repo). Provisioning infrastructure with powershell (on azure) is not the best way of doing things.
Related
For some reason I can't get SQL Server 2017 installed on my Windows 10 machine.
First thing to do with this buggy installer is that I had to uninstall VCRuntime 2017 in order for the installer to work.
And now, the installer is stuck at this point exactly every time I try to install it:
What I've tried so far:
Killing msiexec process
Running the setup with additional parameter as mentioned here
Setup.exe /SkipInstallerRunCheck
Restarting ... reinstalling ... turning off anti-virus ...
[Solved]
The problem was due to a background download that was taking forever especially on a low internet speed (i.e. python or R-support component).
[Solution]
If you really need python or R-support just wait until download is complete
Else, deselect python and R-support from the component list.
(or) kill the child process for python or R-support component downloader from task manager.
UPDATE:
The actual problem turned out to be the R-support component(s) slowly downloading in the background locking up the installation GUI
with no notification or warning show to the user as to what is
actually going on.
So it seems this "locked install problem" can be caused by installing several different components, at least by Python or R-support. As mentioned below, please check any available logs or event logs for clues.
In summary, options:
Maybe try to unselect such components for install if you do not need them.
If you need the components, leave the setup to complete, and check progress in log files as explained below. Verify Internet access (proxy?).
Stuck Download?
UPDATE: Did you see this blog? Looks like the setup tries to download and install the Python runtime, and this can take forever. Are you behind a proxy btw? No direct connection to the Internet? If so I suppose this could also cause further problems. Probably not the cause, but worth a mention.
Apparently you can check the following log file for progress for the installation:
%ProgramFiles%\Microsoft SQL Server\140\Setup
Bootstrap\Log\DATE_TIME\RSetup.log
DATE_TIME in the above path must be converted to your valid values. For example: 20170804_162723 (date part and time part).
See this answer as well: SQL server 2016 installation freeze. You could also try the suggestion to deselect all components you do not need to prevent any background downloads?
General Debugging
Leaving in the general purpose debugging suggestions below.
Generic Advice: From experience I would create a new local admin user and try to install using that account. This is to avoid any "unclean" or special conditions that have occurred in your user profile or registry during regular Windows use. Might not do much, but sometimes it gets the job done with surprising ease. Worth a try I think.
Some Further Things: I wrote up a little check list a while back, I'll add it and see if it inspires some new ideas that can help you. See under "Core Deployment Problems". That first "check list" was condensed from a longer and somewhat excessive first writeup - one of those answers that unintentionally turned into a blog and maybe a hard one to read.
Logging: Did you check log files and / or event logs properly for clues as to what is happening? I find the best approach for deployment to enable logging for all MSI installations. The performance hit it triggers is minuscule compared to the benefit of having a real log-file always available when you suddenly need one. You can enable logging for all MSI files as explained on installsite.org (section: "Globally for all setups on a machine"). MSI log files will then just sit in your %TEMP% folder after installation. They have a random hex name, and you can flush them all regularly if you do not need them. You sort by modify date / time to find the latest one(s) created - obviously.
Jedi trick: You will want to go home and re-think your life if you don't enable logging for all MSI files. Moral of the story: MSI log files are cool. They are very verbose, but they are beautiful. There are some hints on interpreting them here (bottom).
My 2 cents: SQL Server Installer consists of several small MSI installers. MSI installers can only be installed one after each other (as fas as I know). In my case, I launched another MSI setup while installing SQL Server. This caused SQL Server Setup to hold until I finished the concurrently running setup.
So, at least in my case the problem was self-made.
You have to remove configuration settings for SQL Server from Windows Registry editor.
Sql server
2017
VS
By the end of last week our central IT Department introduced SCCM and applied it to a bunch of clients in our division. My colleagues and I work as so called "IT-Partner" in a 1st level support for a few hundrets of colleagues. Now we're facing some problems with our new SCCM System (installed packages do not work etc.) Now we'd like to "reset" applications so the SCCM Agend will reinstall them. I've read something about the detection methods but unfortunatelly I do not really know how they work nor I know where those methods are saved. I want to "analyse" those methods so I know which file to modify / delete that the agent will reinstall the application.
By the way, how much time does SCCM take from "assigning" a package to applying to the client?
Assuming you only have the client and no access to the SCCM Console the detection methods can be found using WMI. They are stored in root\ccm\CIModels in the Class Local_Detect_Synclet.
The format is XML in one column and it is designed so that all kinds of detection methods can basically be represented in the same style so it's not very readable but you should be able to get some basic understanding about the detection method used.
Keep in mind this is only true if the software was deployed in the "new" (introduced in sccm 2012) application format and not for the "old" package/program format.
If you want more detail I once tried to automate the process of triggering a reinstall for any given application but ultimately failed due to problems with the chache/distribution point. I posted all my findings here.
So from an application POV. When you deploy an app the detection method is setup in SCCM to determine wether or not the application installed successfully. This detection method could be configured a variety of ways. For example, it could check to see if the msi code is installed to determine success, it could check the .exe and compare it to a specific version, or even check a registry file for existence. In order to change/modify these detection methods you should be an SCCM admin and be able to login to the console. From there you would select the specific application or package you want to analyze and click through the properties of the deployment.
We are developing some testing infrastructure and I have hit a coders block (lack of sleep?)...this seems like it would be a solved problem but I haven't found what I'm looking for via google.
I would like to automatically push builds from our CI server (TeamCity) to a number of machines (growing, but currently 30). These are several WinForms apps and a number of dlls. Once deployed, I would like to kick off tests (NUnit, for both unit and integration tests) and report all results (back to CI? or somewhere else? Not sure).
The target machines are a number of platforms (Win7,Vista, XP, Server 2k8, Server 2k3, Ubuntu, Fedora, Suse, x64, x86, maybe macs down the line)
This gets me part way there (the actual push). But I can't find existing solutions for 'push starting' the tests and reporting back. So far I am thinking of combining the link (or similar) with custom code running on each client machine that watches the deploy directory, runs the tests and reports the results.
Does anyone know of existing solutions?
Links?
Done something similar and care to share?
Edit
If possible, we prefer .net based solutions, but it isn't strictly necessary. I would have tagged the question as such, but ran out of tags :)
You could use KwateeSDCM to both push and start on all the platforms you mention, including mac. However, you'll have to do some coding to get reports out. I'm not familiar with TeamCity but maybe you could push a script along with your application which could then transfer the test results via ftp to a server accessible by TeamCity.
Have a look at: STAF (Software test Automation Framework)
The Software Testing Automation Framework (STAF) is an open source, multi-platform, multi-language framework designed around the idea of reusable components, called services (such as process invocation, resource management, logging, and monitoring).
Which includes STAX:
STAX is an execution engine which can help you thoroughly automate the distribution, execution, and results analysis of your testcases.
And there's an article here:
http://agiletesting.blogspot.com/2004/12/stafstax-tutorial.html
Assuming you have the push part done already, and you don't mind using a TeamCity license, you can create a TeamCity Command Line Runner build configuration or NUnit test configuration that kicks off the tests on a properly configured agent. The build trigger for this test config would be successful completion of the application build.
So far I have ended up using a seperate build step in TeamCity that executes a bat script that in turn fires of tasks to the list of machines using PsExec. So far my trial runs it is working ok, though I now need to parallelize the copying of build output...
Thanks for the input to those who have provided it.
I've got a small WPF application which is being deployed to a client soon. One of the prerequisites is Sql Express 2008, and the clickonce installer handles that part nicely. My issue is that, after installation, I need to be able to unzip a backed up SQL DB, restore it, and set some user privileges. I have the SQL and the code needed to do this, but I can't seem to figure out how to inject it into the clickonce install process, or how to force it to run some kind of "update" right after installation, before loading up the application. Is there any way to do this?
Consider checking IsFirstRun in your application and performing additional setup at that time. Using this method you can do just about anything you want. Here's a snippet from a webpage with more details:
Use IsFirstRun to determine whether
you need to perform any one-time
initialization operations the first
time your application runs.
Did you have a look at this? You could create a custom action.
I am not sure whether or not you will have/need elevated permissions but it might be worth a try,
I have just completed (basically) a beginner's database application with SQL Server and Visual C#. I am using Visual C# Express, not the full-scale Visual Studio thing, which apparently makes deploying the application properly a bit more complicated. I've seen where some other people have asked about how to deploy such an application from that IDE, but I'm not able to fully understand and use some of the answers that they've been getting back.
Therefore I must ask how to deploy this application properly, but I must also ask that there be a simple walkthrough given. College doesn't teach much about how to deploy these things, so I'm very newbish at it. Thanks!
I don't know of an automated way to deploy the database. If it's the first time the database is hitting the server, I backup on the source, and restore on the target...simple.
As far as the code, here's what I do:
Publish (right-click, Publish) the code to a local directory (I use C:\Websites\SiteName).
Use and ftp client to promote the output to the server.
Make any necessary adjustments to the web.config to point correctly to your target database.
When and if you need to make changes later, you might want to consider a tool I use for this purpose, BeyondCompare. It can perform a diff between your local files and the target site via FTP, and tell you exactly what you need to deploy to make it work. This won't detect changes in your db, however, though there are plenty of Sql diff tools along the same lines. My general principle is "make the local site work perfectly, and then make the target site just like the local site".
Things to watch for in #3 above are that the target address is right in the connection string, along with whatever security credentials you will need to connect to the db.
HTH.