I am looking for a ARM Template to add an existing VM to a update management enabled on Automation account.
How can i associate a VM to the update management?
Related
In our organization, currently we have our Windows SQL server machine in on premise. And we are planning to move that to Azure VM. And now my question is, while creating the new Azure VM is it possible to set the IP address that what we have for our current on premise machine. So that after the migration, we don't need to do any config connection settings changes.
Bring-your-own-IP is currently not available on Azure. There is an open Feedback item (which says it is Planned). https://feedback.azure.com/forums/217313-networking/suggestions/4127175-bring-your-own-public-ip-address-space-and-interne
I have an Azure VM (windows Server 2016 and SQL Server 2016) running a production web app that serves as both the app and db server for performance and cost reasons. There is some corruption that has caused various issues like windows updates fail, SQL Server auto patching fails, can't open SQL Server Configuration tools, etc. I'd also like to upgrade from SQL Server to a newer version (2019) for some features.
I've read that it is not possible to do an in-place version upgrade, so the recommended path is to spin up a new VM with the latest SQL image and migrate from the old to the new. I know that link is for an Edition upgrade, which it seems they now do support. But I haven't seen this as being possible on version upgrades. As such, I assume migration is still the path?
I have 2 data disks on the current VM to house the data and log files that I can move over to the new VM...but there are a lot of other aspects to consider like public IP, network security group, SSL Certs, IIS config, etc.
I'm an app developer, not a windows admin, and new to Azure as well. Are there any check lists on how to do this as painlessly as possible? My google searches were fruitless (got moving to different regions, migrating from SQL server to Azure SQL, etc). For example, create the new VM, move the data/log disks over to the new VM, restore the DB on the new VM, script out SQL jobs/logins from source to new, point the external IP and NSG to the new VM, manually create IIS websites and reinstall SSL certs....
As far as I know, currently, you still need migration VM for SQL version upgrading as that answer explained.
In fact, you have found the main steps in the migration path. You will backup your important data and logs, backup the DB and the web app, export the SSL certs. Then you will create the SQL virtual machines with a new image SQL server 2019 on the Azure portal. Then you will import the SSL certs and configure IIS websites, restore the DB on the new VM, script out SQL jobs/logins from source to new.
When you create the new Azure VM, you can deploy the new VM in the same region and subnet as the old Azure VM, you can also attach the new Azure VM with the old subnet level NSG. Optionally, a new public IP will be assigned to the new Azure VM, you will use this new Public IP to connect to your web app and DB. After validating the deployment, installation, and configurations. You can remove the old Azure VM, Network interface, old SQL OS and data disks.
For more information:
Migrate a SQL Server database to SQL Server in an Azure VM
Associate network security group to subnet
Move or copy an SSL certificate from a Windows server to another Windows server
I have created an application which is an window service which has to run under context of domain administrator account and take some server settings etc stuff.
Now I need to install it on client machine, obviously I can not do it using normal deployment project MSI because it involved custom dialog and user input while installation.
How can I do this?
Now Is there any 3rd party framework which really allow me to create custom dialog and write code which will execute at runtime?
If I have to do it manually? How I will incorporate my custom installer files and my windows server application files into a single MSI.
This is how I want to have my installation process:
Welcome Screen
System Checks
EULA
Server settings as per product licensing, its a radio selection by user.
Server settings based on last selection.
my window server settings which will make a rest call and update server.
accepting domain user account credentials.
Now installations starts.
Redirection to cloud portal with finish message based on selection.
What you need is supported by MSI installers, but mostly by commercial setup tools. The server communication is usually done through built-in support or through custom actions.
Here is a list of setup tools which can get you started: http://en.wikipedia.org/wiki/List_of_installation_software
For example, Advanced Installer has built-in support for server-side license validation and communication.
Pick a setup tool and try to create your installer. You can then ask more specific questions if you encounter any problems.
We have an application, consisting of an MS Access frontend (2007, mdb format), a few .net libraries and an SQL Server (2008) backend. I am working on an installer, which automatically installs the MS Access Runtime, our application, our libraries, SQL Server Express and configures everything.
Clearly, the MS Access application and the libraries (running in a normal, non-admin user context) need access to the SQL Server database. What is the best way to grant access to the application?
This is what I came up with. Unfortunately, all of these seem to have drawbacks:
SQL Server Compact Edition: Does not support views.
Application Roles: This seems to be best practice. However, it requires executing a stored procedure before accessing the database (I cannot pass the app credentials in the connection string). Thus, I cannot use this to attach the SQL Server tables as a linked tables in the Access MDB, which is a requirement of our Access application.
SQL Server User Instance: To quote from MSDN: "This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work..."
SQL Authentication: Microsoft says: "When possible, use Windows Authentication."
Using Windows authentication and granting BUILTIN\USERS full access: This is by far the easiest solution, but somehow it "seems wrong" to do that...
The application is targeted at a non-technical audience, so asking the user to configure permissions is not an option.
EDIT: Some clarification: It's a "local" application, i.e., the SQL Server is located on the same machine as the application; SQL Server access from the network is neither necessary nor desired. The software (a regular business application for managing stocks, invoices, etc.) will be available to download for free, so it should run in a variety of environments (domain/non-domain, different operating systems, etc.), and IT knowledge should not be required to install it -- apart from the usual "click on setup.exe, confirm UAC prompt, acknowledge the installation directory, etc.". I expect the most common scenarios to be "Windows XP, local admin user" and "Windows Vista/7, local admin user with UAC enabled". Since we want to follow good practices, running the application should not require "Run as Administrator" in the latter case.
#Heinzi write:
Using Windows authentication and
granting BUILTIN\USERS full access:
This is by far the easiest solution,
but somehow it "seems wrong" to do
that...
The usual approach here is to add a custom user group (e.g., "db-users") and put the users in that group. That way you can control exactly who is allowed access.
How about:
Use an Access ADP project, pre-configured to connect to the locally installed SQL Server instance.
Connect using BuiltIn\Users group (or SQL authentication) but grant only the bare minimum credentials. Enough to logon and ...
Call sp_setappprole to "elevate" the client connection to your defined application role's identity.
If sound like you have only got the tie of the iceberg. When it comes to selling and deploying access SQL applications.
I have take a different route. I have virtual computers as standalone workstation and domain server and workstation all virtual.
I have write a scripts they are a combination of VBA and VBScript.
Ask
Is the DB and App to run on single computer or different computers.
If different computer what is the name of the computer the DB is located on.
Is the DB and App to in a workgroup, homegroup or domain environment
Is the DB computer already have SQL Express or above
Is the App computer already have Access or Access Runtime installed.
If yes which version.
Will all or only limited users have access.
If limited what is the user group name of user to be have access to the data.
Does this group already exist
If No List the Name of the Users that Should Be Added to the Group
Also questions about the Admin Users and Group
The script start the virtual machines and goes through a series of steps to rep the MDB and SQL DB for deployment. Then creates an MSI for the Server Install with include a custom script that sets up the environment. Finally packages MDB in a nice MSI.
I have since enhanced the process to allow some questions to be answered at the beginning of the server installation. This means the user groups and users can be selected from the lists in the workstation or domain depending on prior questions asked.
If user the app user is a member of the Admin Group of the Workstation or Domain. They get extra menu options. That allow them to add or remove members from the DB user group for the workstation or domain. This I find is helpful.
I am now moving to the next stage and looking at hosting my assess app as an SasS (Software as a Service) (Rental). So the app can be use in any HTML5 Browser, Windows or Mac as Virtual Desktop or Android and Apple device. Having said that Access is a bit ugly on mobile devices.
When I am up and running I will make the platform available to others.
Is there a way to change the location of the SQL Management Studio 2005 Registered Servers?
We want to use the same registered servers inside our team, so it would be great to point to a network location, so after changing a server it will automatically be visible to other team members. The export / import functionality still needs manual steps to get an update of the server list.
I don't know of any way to share the same registration set on multiple computers. But maybe this can help:
http://www.developer.com/db/article.php/3587206/Drilling-Into-SQL-Server-Management-Studio.htm