I'm trying to test a migration of moving a BizTalk SQL Server from one server to another. Here are the details.
Currently it was all on a single server in a dev environment, BizTalk SQL, SSO and BizTalk runtime all on one server. It is a Windows 2008 R2 server with SQL Server 2008 R2.
What I want to do is split out the SSO Master secret server and BizTalk databases to a Windows Server 2012/SQL Server 2012 setup. So far I got SSO all setup on the new SQL server. I configured just the SSO portion on that server and all went well.
I then unconfigured the existing BizTalk Runtime and then went to configure again, using the new Windows/SQL Server/SSO in the configuration process.
All goes well up to the point where it tries to configure the BizTalk runtime. That being said all the database are created, SSODB, BizTalkMessageBoxDb, all of them. But when it goes to configure BizTalk Runtime, it hangs for a while and several of the following errors show up in both of the Server's logs:
Could not access the SSO database. If this condition persists, the SSO service will go offline.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding..
SQL Error code: 0xFFFFFFFE
It shows up in the SQL/SSO servers logs first, then the Runtime server a few seconds later. Eventually the configuration times out and fails. I believe it's permissions related, but I can't seem to figure out what it would be.
Questions:
what permissions do I need to review?
would the fact that the new server is Windows 2012/SQL 2012 while the runtime server is Windows 2008 be an issue?
is there any way I can get more details on this error?
Edit to add both DTCPing and DTCTester pass with flying colours and I can connect to SQL via SSMS from the server. Firewall has been completely disabled for now in order to eliminate that as well.
How were your service accounts configured in the first environment? Typically a single DEV environment with everything on one box can be done by using a local account on that server. If you now split out your SSO onto another server (it doesn't matter if it's W2K12 instead of W2K8), you are going to have to switch your service account(s) and groups for BizTalk to Domain accounts.
In a multicomputer environment, BizTalk Server supports only domain groups and domain service accounts. Domain groups include Domain Local groups (not recommended), Global groups, and Universal groups. Built-in accounts such as NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\SERVICE, NT AUTHORITY\SYSTEM, and Everyone are not supported if you want to configure BTS in a multicomputer environment.
Make sure your SSO is running as a domain account, and a member of an SSO Administrators domain group - and ensure this domain account/group combo is configured for the SSO system on the SQL server (instead of local accounts):
After that the SSO system you join from the BizTalk Server before configuring the runtime on BizTalk Server usually needs to be configured with the same domain service account for SSO:
Related
I've setup a Service Broker on one of databases to automatically pick up stored procedures in a specific schema (Build) and run them on a daily basis. So far everything has been running fine, however we've now got a need where we need to access a remote sql server which is running SQL Server 2017 and has the latest Machine Learning Service installed.
I've given the service account that runs the primary SQL Server (SQL 2016) access on the remote server, and ensured the Service Broker is executing under the service account, rather than the local SQL account (sa).
Whenever we try to access the remote server, we are getting the following error:
Linked servers cannot be used under impersonation without a mapping
for the impersonated login.
I've tried adding an EXECUTE AS to the process, however this doesn't seem to make a difference. I've also ensured it is running under the service account, and it is.
I can get it to work using a mapped login on the linked server, however this isn't ideal, as we don't want to run the sql server in mixed authentication as this has been determined as an IT risk.
I've run out of ideas or what I can do here, and can't find any other help pieces with this same problem. I did want to roll this process out to more of our warehouse builds, however this is a deal breaker at this stage.
help?
I am trying to configure BTS 2016 3.12.774.0 against SQL Server v 17.9.1. They are running on separate servers running Windows server 2016 64 bit OS.
The Enterprise Single Sign On database (SSODB) and the Business Rules Engine DB (BizTalkRuleEngineDB) get created but only to BRE is configured when I go into Biztalk Config.
I have had the servers rebooted but no change.
The Ent SSO Service does not exist in Services
User doing the install is in groups Biztalk Server Admin, Application Users, Server Operators and SSO Admin, Affiliate Admin all at the domain level.
Names of both servers are 13 characters.
Not sure what to look for in the configuration logs. I have searched for the words Error, Fail, Exception but there are none.
A new attempt to configure gave the following error:
Microsoft BizTalk Server Configuration Wizard ------------------------------ Failed to create the SQL database 'SSODB' on SQL Server 'servername10' (with SSO Administrator account 'SSO Administrators'). (SSO) For help, click: go.microsoft.com/fwlink/… ------------------------------ ADDITIONAL INFORMATION: (0xC0002A21) An error occurred while attempting to access the SSO database. (SSO) For help, click: go.microsoft.com/fwlink/… ------------------------------ An error occurred while attempting to access the SSO database. See the event log (on computer 'servername10') for more details. (SSO)
There is no SQL Server v 17.9.1. That version number is one for SSMS.
BizTalk Server 2016 does not support SQL Server 2017. Hardware and Software Requirements for BizTalk Server 2016
Please post the error text, either from the little red X or the error log. There will always be an error. BT Config will never silently fail.
I have a sharepoint 2010 portal with some dashboards and reports. No I have a permission problem, because I cannot view these reports.
I would like to have a look in Reporting Services Configuration Manager, but I cannot connect to the server where sharepoint and SQL server is installed. I enter the server name and press on find. It gives me the following error:
Unable to connect to the Report Server MYSERVERNAME.
By the way, I try to fix this problem:
AccessDeniedException: The permissions granted to user
'Mydomain\MyUserAccount' are insufficient for performing this
operation.
First off, you probably want to be using SharePoint Central Administration, not RS Configuration Manager. Also, RS Configuration Manager isn't where you'd manage access to report objects.
That said:
Try remoting into the host machine and running the tool locally on the server.
Ensure the proper ports are open for you to be connecting remotely (and that they SHOULD be open - there are very valid security reasons to block them)
Are you 100% certain you're connecting to the right address? Is it possible the SSRS service itself is on a different machine than the Sharepoint service and the SQL server?
have a .net app that talks to a locally hosted MSDE instance -does anyone know the user account the MSDE runs under?
The business sysadmins have released a bunch of "upgrades" to PC's (apparently for active directory and a bunch of other stuff) and now the app cannot connect to the database - so we figure the user account may have been deleted.
Buzz
MSDE - I haven't come across that in a while, that dates back to SQL Server 2000! (MSDE was replaced with SQL Server Express in 2005, so you're a bit out of date).
Anyway, MSDE runs as an NT service, and every service (at least up to Windows Vista) runs under a user account: often one of SYSTEM, NetworkService, or LocalService (Windows 7 and later introduces the concept of Service Identities, which is complicated). You can also run a service under its own user identity, which can be a built-in principal like SYSTEM, a local user account, or a domain account.
I've forgotten the defaults that MSDE uses, but considering it was made in 1999/2000 before NetworkService was invented, it probably runs under SYSTEM or LocalService. To be sure, check your Services.msc listing.
As for the failure-to-connect, that could be caused by anything: firewall, configuration error, etc, not just a wrong service identity.
So anyway, check your services.msc and your Application Event Log, then report back with your findings.
I have the following scenario:
A web application deployed over an NLB and a SQL Cluster.
In the database each table has a trigger to track activities done by users.currently the triggers are saving HostName (which is not useful in case of such web deployment).
Connection to the db is impersonated with the account "SA", Is there a possible way to obtain the
connected user or the workstation sending the request inside SQL or I need to pass User Info into the db from withing the applications Code.
The DBMS is SQL and the web application is based on .NET framework
You need to pass in the user id from the code unless you set up Kerberos pass through to use Windows Authentication. That is out of scope for this answer.
More importantly, why are you running a web app using "sa" on the SQL cluster. This is idiocy. Use a "least privilege" windows service account to run your IIS App Pool and use this to connect to SQL Server.