I have recently followed the steps of upgrading Service Bus 1.0 to Service Bus 1.1. I am at the step were I am using PowerShell to run "Invoke-SBFarmUpgrade" and the commandlet is failing with:
Invoke-SBFarmUpgrade : Upgrade encountered an exception in upgrade_GatewayDatabase_2.13.0.0_1.7.81.0: Online index operations can only be
performed in Enterprise edition of SQL Server.
I don't see an option in the common parameters to be able to set the rebuild option to offline. How can I get over this hurdle?
If this isn't possible, can I create a new Service Bus Farm using the configuration wizard and reattach the Workflow manager to the new farm?
Any help would be appreciated. I'm stuck
Open C:\Program Files\Service Bus\1.1\CommonGatewayStoreUpgrade.sql and replace ONLINE = ON with ONLINE = OFF.
Now you can run Invoke-SBFarmUpgrade and it will work.
(It's probably a good idea to undo your changes to the *.sql script afterwards)
Related
I have downloaded opshub tool for the migration, trying to migrate from on premises to visualstydio team service. Getting error On the migration summary page with error message:
"Unable to communicate with the required process opshubtfsservice.Because probably it is not running. Restart application & try again"
I verified the opshub service is running as local service. I tried to restart & tried with Network service/local account etc. But no lock.
Can you please help me on this here.
Thank you.
It seems that your machine is behind a proxy and all traffic in-out is being routed through it. (Including the communication of local traffic)
You will have to bypass local addresses from the proxy as well as enable OVSMU to communicate through the proxy.
Please refer the C:\Program Files\OpsHub Visual Studio Migration Utility\Other_Resources\Resources\ProxyUtility.zip to configure OVSMU to utilize your proxy. There should be a user guide document which lists the steps.Keep the bypass local address value as default.
In my installer I have a component that installs an NT service. I have a problem that during minor upgrade the service is not stopped. I observed the log generate by installshield during upgrade and it reports it is doing the action StopServices and its return code is 1. I have also started process hacker to log for services start/stop events but the service is never stopped during upgrade. I have also verified that during uninstall the service in stopped and then removed. Any idea why this is happening?
I am using installshield 2008, but any installshield related answer will be really helpful.
Eventually I was not able to overcome this issue. Spent several days trying to figure out what exactly is going on and was not able to figure out why the service is neither stopped nor started during minor upgrade. I was forced to write custom actions that perform this operations and used sc.exe for them. This is not the first unsolvable issue in installshield that I was forced to fix with a custom action. Hope this answer will save several days to someone.
It can be done by install script and a custom action that executes it.
An example for stopping/starting a service (i used it in IS2016):
#include "ifx.h"
//Function to stop the service
export prototype stopService(HWND);
function stopService(hMSI)
begin
ServiceStopService ( "my service name" );
end;
//Function to start the service
export prototype startService(HWND);
function startService(hMSI)
begin
ServiceStartService ( "my service name" ,"");
end;
In order to run the custom action during minor upgrade only, set its condition to:
REINSTALLMODE=vomus
I am trying to install nservice bus on a fresh win server 2012 box and things are not working properly. Any help is appreciated..
I get setup failed prematurely and when I dumped into log file.. this is the error I get..
Calling custom action NServiceBus.Wix.CustomActions!NServiceBus.Wix.CustomActions.CustomActions.InstallMsmq
Installing/Starting MSMQ if necessary.
CustomAction InstallMsmqAction returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 16:36:36: InstallFinalize. Return value 3.
Action 16:36:36: Rollback. Rolling back action:
Do I have to manually add MSMQ features.?
Yes you need to enable the MSMQ features first.
BTW, the MSI is really only to be installed on developers machines, to prepare a machine in production use the powershell cmdlets, see http://docs.particular.net/nservicebus/managing-nservicebus-using-powershell
Is your dev machine a WinServer 2012?
I am deploying project with developer-targeted setup using Inno Setup. I've wrote some code to make some actions that are a bit too custom for the original Inno Setup.
One of such actions was connecting to and running SQL files, thanks to StackOverflow users I've found some code for doing so. The problem is that whenever I try deploying the project on a new Windows Server 2008 machine (x86), I'm getting such cryptic error on every sql command apart from the first one:
"Not enough storage space is available to complete this operation ProgID: ADODB.Connection"
So. The first command fires and works, next stop with error. If I'd run the code again, some of the commands might work, but at some point, the installer would hung. The problem does not exists on windows XP I am writing it on.
I use the code linked above for every SQL command I run (new ole object ADODB.Connection, new command, execute... end) - I don't make the second query for results of insert (as it's there just for showing purpose).
Any thoughts what can be happening here or how can I make a workaround?
I have a question regarding Data-Tier Application (DACPAC) upgrade when deploying to a SQL Azure database. When we upgrade the DACPAC manually through the wizard UI, there is a step where we review the data-loss warning report and have the ability to save the action report to an HTML file (See here under "Review the Upgrade Plan Page"). The Action column displays the actions, such as Transact-SQL statements, that will be run to perform the upgrade. The Data Loss column will contain a warning if the associated action could delete data.
Right now, I'm automating the database upgrade process using Powershell, which works beautifully so far. Unfortunately, I couldn't find a way for it to generate the same data-loss warning report.
An excerpt of my Powershell upgrade script is below:
## Generate the database change list (database drift) and upgrade script and save them to file.
$dacChanges = $dacStore.GetDatabaseChanges($dataTierAppNameToUpgrade) | Out-File -Filepath .\DatabaseChanges.txt
## Getting the DAC incremental upgrade script for data-tier application
$dacStore.GetIncrementalUpgradeScript($dataTierAppNameToUpgrade, $nextDacType) | Out-File -Filepath .\DatabaseUpgrade.sql
The DatabaseChanges.txt output file generated by GetDatabaseChanges() wasn't really informative, so we are wondering if there's a way to get the same report file as the one we would get if we were to go through the upgrade wizard manually. This report has been a great help to the deployment team when resolving data migration issues, and we would like to be able to inspect it manually when we deploy to a live production database.
We've searched through the MSDN documentations but didn't have any luck.
Does anyone know if this feature is supported for Powershell deployments?
Is it a plan that this will be supported in the near future?
Thanks for your help in advance.
According to http://technet.microsoft.com/en-us/library/microsoft.sqlserver.management.dac.dacupgradeoptions.aspx, by default IgnoreDataLoss is false, which means if data loss is detected, the upgrade will fail. In .NET, you can handle the DacActionFinished event (http://technet.microsoft.com/en-us/library/microsoft.sqlserver.management.dac.dacstore.dacactionfinished.aspx), which will fire when the upgrade operation finishes. If something goes wrong, the event arg’s Error property (http://technet.microsoft.com/en-us/library/microsoft.sqlserver.management.dac.dacactioneventargs.error.aspx) will contain the detailed exception. It may not be the html report you want, but it will still give you some information. You can handle CLR events from PowerShell. Please refer to http://blogs.msdn.com/b/powershell/archive/2008/05/24/wpf-powershell-part-3-handling-events.aspx for a sample.
By the way, actually the issue is not only specific to SQL Azure. You can also modify your tag to SQL Server to get further suggestions.
Best Regards,
Ming Xu.
Just got in touch with the owner of DAC # Microsoft, and here's the solution he suggested: it is possible by using their managed API or through SqlPackage.exe.
SqlPackage.exe has an action on it to produce a deployment report. If there is a possible data loss issue detected it will be included in the report.
Reference: http://msdn.microsoft.com/en-us/library/hh550080(v=VS.103).aspx