I have a virtual server in azure with sql on it which I enable the backups from within the Azure Portal (which uses the SQL Extension) I need to disable that now as it interfering with my log shipping.
However, I cannot disable the backups or change any of the SQL settings from Azure because the SQL Extension is in a Transitioning status.
I have tried rebooting the server already. The only option I can see is to uninstall the SQL extension from the Azure portal but I don't know how to re-install it as its not on the list of extensions to add. Any suggestions would be greatly appreciated
Related
Requirement: I wanted to copy data from a specific table/view residing on a on-premise SQL Server to Azure SQL DB.
Infrastructure: As depicted in below picture. Essentially, the Azure network is directly connected with corporate network over Express Route. Thus it's a pure private network connection; as good as the corporate network itself.
Issue/Question: I know there are multiple approaches present to get this operation done and I am not restricted to use ADF copy Data tool only. BUT, for all of these I see some cavets or extra steps needed to be done as below:
ADF Copy Data Tool: Needs a SH-IR and a small MSI package needs to be installed on on-premise machine which hosts the SQL server for registration purpose.
Logic Apps: Needs a Virtual Gateway (OR) ASE
App Service: If the operation is wrapped in a C# application and I choose to deploy to a Azure Web Apps. Then in-order to connect to on-premise SQL Server we need to setup hybrid connection manager and as in #1 we need to install something in on-premise machine.
For my case, none of these extra steps can be done. essentially, the on-premise SQL Server comes under a different BU and thus I don't have any permission there; except they have given grant to a table/view. Thus, none of these extra shitty steps can be done.
Moreover, as mentioned above; since it's connected over express route as direct connection, As can be seen in above picture, both the on-premise and azure SQL are essentially inside the same corporate network. THUS, I should be able to access them directly without configuring any of these extra steps as mentioned above.
Please confirm on these and provide a suggestion.
Thank You.
You can still go with the ADF scenario without a SHIR by creating ADF in a Managed VNET using Private Endpoint. As you already have an ER circuit and have the flexibility to configure the Azure side, can you do this with Azure IR: Access on-premises SQL Server from Data Factory Managed VNet using Private Endpoint - Azure Data Factory | Microsoft Docs
There are 2 solutions which could work for your scenario but even for them to work ,you would need access to on prem SQL server machine access to some extent atleast for one time config and Azure SQL db should be accessible via SSMS installed on on-prem machine.
Using linked server
You can create a linked server ( process explained here https://www.sqlshack.com/create-linked-server-azure-sql-database/ ) on on-prem server and create a agent server job to insert data to azure SQL db table.
Via Python Script
This would need Python installation on on-prem machine. Once installed you can write script to transfer data between on-prem SQL server and Azure SQL db. You can schedule this script again by using an agent server job.
Our new system handle HIPPA data and has security equirements.
Azure handles secure connections, but we're looking at TDE as well.
One of our consultants said that TDE is possible by creating a virtual server in Azure and loading SQL Server 2012 Enterprise edition directly on to the server. This would be outside of the Azure provisioning. Would this work?
I know that a recent release that's currently in preview that would accomodate TDE. Does any one know were I can get the preview version?
Thank you for your help
From your description, I'm assuming you're referring to running SQL Server in an Azure VM. If that's correct, TDE has nothing to do with Azure provisioning.
You can pick any of the SQL Server VM templates available that supports TDE. After Azure completes provision of the VM, you can login to your SQL Server and enable TDE. You can certainly still upload your own VM image but unless you have some corporate standards, pre-installed software, etc... a regular provision is probably the easiest and fastest.
I am a total newbie in SQL/SQL server stuff, and I am using SSRS to make a new reporting server/service and upload some .rdl files to it
I have a reporting server on a machine, which has a lot of reports and data sources uploaded to it's database.
I created a new reporting server with a fresh database on another machine, and what I want to do is to copy the old database content to the fresh one (the reports and the datasources..etc)
I have no copy of the individual reports to upload them to the new server using localhost/reports
is there's a fast solution to what i am having? please do it in detail because I never worked with SQL before.
Different ways to do this:
Report Server Databases
Use the detach/attach or backup/restore instructions here. Both of these methods require a backup of encryption keys on the existing instance, which are then restored to the new report server instance. Instructions on backup/restore of encryption keys here. Migrating the ReportServer and ReportServerTempdb databases is the easiest way to ensure all content is available on the new server.
Report Object Scripting
Reporting Services Scripter is an older (but still working with SSRS 2008R2, not sure about 2012) tool that can be used to transfer objects (folders, shared data sources, shared data sets, reports, etc) between report servers. Good choice if you want to pick and choose what is migrated.
If you are receiving an error regarding unsupported scale-out deployment, this means you are running Standard edition and need to remove the old report server entry from the database in the new location. It can be done using Reporting Services Configuration Manager, or by using rskeymgmt at command line.
Reporting Services Configuration Manager
Open Reporting Services Configuration Manager and connect to the new report server instance.
Click on Scale-out Deployment to view registered report servers.
Select the old report server instance and click the Remove Server button.
Command line and rskeymgmt
Browse to the Tools\Binn folder of your SQL Server client installation.
Run the following to list registered report servers
rskeymgmt -l -i
Using the installation ID (GUID) of the old report server, remove it
rskeymgmt -r -i
More info on scale-out deployments and rskeymgmt here.
To migrate Reporting Services, use migration manual from MSDN (https://msdn.microsoft.com/en-us/library/ms143724(v=sql.120).aspx). If you encounter "the feature: scale-out deployment is not supported in this edition of reporting services. (rsoperation notsupported)" error, go to ReportServer database and remove the old encryption key from table dbo.Keys.
I am working on DW with SSAS cube. While development, my Cube is hosted on SQL SERVer 2008R2 on a development Server (Windows Server 2003).
Now, post to development phase I need to host the cube on test Server which would be on a remote location to which I do not have the access.
What are the possible ways I can host it on the server keeping in mind that If needed I need to re-deploy on server from BIDS Studio (when some bug arises).
What credentials I'll be needing (Will it do If I have a SQL sys rights or a windows account in that domain is a must)?
Thanks in advance!!1
In theory you shouldn't worry about it, taking into consideration of course, you have someone with access to the destination server.
You should never use BIDS to deploy your cube, it cant deal with partitions or security for example. Every deployment would overwrites these management settings of the target server.
Instead, you should use the Deployment Wizard to create your script and the you would send it to the person responsible for the deployment.
If you need more info about the deployment wizar, check my answer on this post
I had a SharePoint server, now i want to move this from one machine to another machine.
This is what i did for the migration.
I have just installed sharepoint server in my new machine and i have removed the Sharepoint_config and wss_content databased from the new server. and i have restored both the databases from the old server. Then i tried to run the Central Admin and i got Unable to connect to content database error.
Is replacing the DB is wrong. is there any other way to migrate SP server from one machine to another. I have tried my taking Farm backup and restore i had many problem with that. so i feel replacing DB would be better for me. any suggestions please?
Move SharePoint between servers is a huge effort.
Data in databases are very depends on the SharePoint install and its environments. So, I suggest just re-install the SharePoint on the new server, and then restore site collection backups to the new install.
Install SharePoint Server on the new server machine
Backup site collections from the old server, follow this guide: http://technet.microsoft.com/en-us/library/cc263441(v=office.12).aspx
Create Web Applications on the new server
Restore site collections from the prev. backups, follow this guide: http://technet.microsoft.com/en-us/library/cc262087(v=office.12).aspx
Be aware, if you have farm level customize solutions (developed by Visual Studio) or css files deployed in the LAYOUT folder, don't forget to re-deploy them on the new server.
I guess this question is too old and my answer will not help topicstarter... However, I was looking to refresh my own knowledge on this topic and I feel it will be useful to share it here.
This solution is not good for every SharePoint deployments, of course, it's just a general idea.
And I don't think it suits production environments well... but if you are brave and foolish as myself, you can do it there as well, with some additional precautions like backups and so on.
Here are prerequisites:
SharePoint was initially installed in Farm mode (not in Single Server mode)
Both old and new servers are in the same domain
You know Farm Passphrase used for initial installation
Old server is still intact and accessible from the new server
Steps to do
Skip steps 2-6 if you don't want to move databases to new location
Install SharePoint on the new server and join to existing farm. See
https://technet.microsoft.com/en-us/library/cc261752.aspx for details on joining procedure.
Ensure that the SharePoint is read-only. You can just shut down MS SQL DBEngine service if it's ok for your users.
Install MSSQL Server on the new server or other location you want. Remember, that it's not a good idea to keep SharePoint and MSSQL on the same server if it's not a demo/dev environment
Move all SharePoint databases to the new MSSQL Server. You can simply copy all DB files and attach it to the new SQL, or go full backup and restore way.
Important: Create an SQL client alias on the new server with cliconfg tool. See blogs.msdn.com/b/priyo/archive/2013/09/13/sql-alias-for-sharepoint.aspx for details.
Use your old SQL instance name as alias name. E.g. if your old server had SQL installed alongside with SharePoint on SharePoint.mydomain.com, alias name should be "SharePoint.mydomain.com"
Set Server name for alias to the new SQL location. Something like "NewServer.mydomain.com"
Ensure that you specify correct port number for SQL connection or configure network for default dynamic port. It is not necessary only if you have local SQL server on the same machine.
Create identical SQL client alias on the old server (this is needed to correctly remove old server from farm)
Remove old server from the farm. See this technet article for details
Update DNS settings or whatever you use to point users to the new server.
That's it. Hope it will help someone