While configuring the clustered SSO on the second server, I got an error, while running the command :
C:\Program Files\Common Files\Enterprise Single Sign-On>ssoconfig
-restoresecret SSOSecret.bak Password : ******* Confirm Password : *******
The error is :
Could not contact the SSO server ''. Check that SSO is
configured and that the SSO service is running on that server. (RPC:
0x800706D9: There are no more endpoints available from the endpoint
mapper.)
The architecture is the following:
A windows Failover Cluster, with two nodes, each with BizTalk Server
A second Windows Failover Cluster, with two nodes, each with SQL Server. Always ON is on.
The SSO db belongs to an availibity group.
The error occurs when trying to restore the secret on the second node.
The SSO is installed on the SQL Server cluster. I configured the SSO (BizTalk configuration tool) on the two nodes. On the first, I created the SSO group, on the second I joined the group.
I configured the cluster resource by selecting the "Use Network Name for computer name", but I still have the same error while restoring the secret.
There a few things you'll need to do at some point.
You run -restoresecret with the MSS running on that node.
The Enterprise Single Sign-On Service resource needs a dependent Network Name.
The Use Network Name as computer name box must be checked.
Related
We have implemented AppDynamics in Jboss application. We have load balancer and autoscalling which means we will have node registration when new server comes up.
The problem here is Java and Machine Agent. Java Agent can reuse name with prefix (Appd Controlled Node Names) , but machine agent node name need to be provided at configuration level.
We are getting two separate agents listed. One is 100% with Machine Agent and another with Java agent. We need Machine Agent will ping at same line.
https://i.stack.imgur.com/MhpeU.png
The Issue is resolved.
The controller-info of Machine Agent need not to have any Application,Node and Tier name. It should include unique host id which should be same as controller-info of JavaAgent.
EDIT: One important detail that I original left out (because I didn't know it was important) is that we were running these sites in full IIS, not from IIS Express.
We're trying to setup local dev environments for Kentico CMS that will add our local machines to our current synchronization chain of Dev --> Staging --> Prod (so we'll wind up with Locals --> Dev --> Staging --> Prod).
We copied our Dev DB to our local machines onto the (localdb)\v11.0 instance of SQL Server, but we're running into an issue on everyone's computers except mine.
Here's the error we're getting:
The application could not connect to the database, please check the
connection string in the web.config file and SQL server availability.
Original error:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 50 - Local Database Runtime error occurred.
The specified LocalDB instance does not exist. )
I've tried a ton of suggestions from other SO answers and other websites to figure out why we're getting this error (and why it's not happening on my machine), but no luck. We can connect to (localdb)\v11.0 in SSMS but we cannot connect to it through VS (same error). Also, when we open Sql Server Config Manager, we're not seeing any listings for SQL Server Services. Any ideas?
Make sure you have .NET Framework 4.0.2+ installed
Set up your AppPool to run under the NetworkService account.
Create a login for that account in your db.
USE [master];
CREATE LOGIN [NT AUTHORITY\NETWORK SERVICE] FROM WINDOWS;
EXEC sp_addsrvrolemember N'NT AUTHORITY\NETWORK SERVICE', SYSADMIN;
Share your instance with all users by running
SqlLocalDB share Kentico KenticoShared
Use connection string in the following format:
<add name="CMSConnectionString" connectionString="Data Source=(localdb)\.\KenticoShared;Initial Catalog=KenticoDB;Integrated Security=True;Connect Timeout=60" />
If it doesn't help use a named pipe:
<add key="CMSConnectionString" value="Persist Security Info=False;Integrated Security=SSPI;database=KenticoDB;server=np:\\.\pipe\LOCALDB#D2BA6590\tsql\query;Current Language=English;Connection Timeout=120;" />
Notes:
the exact name of the NetworkService account on your machine can be determined by running following C#
var ns = new SecurityIdentifier(WellKnownSidType.NetworkServiceSid, null).Translate(typeof(NTAccount)).ToString()
named pipe can be determined by running this in CMD: SqlLocalDB info KenticoShared
don't forget to run your instance SqlLocalDB start KenticoShared
Seems a little obscure, but have you looked at http://support.microsoft.com/kb/941823 , "Some or all SQL Server 2005 services are not listed in SQL Server Configuration Manager..."?
And there are generally two things that get in the way of connecting to SQL Server from an application even though you can connect using Management Studio. First, you should make sure that TCP is enabled on the instance, http://msdn.microsoft.com/en-us/library/bb909712(v=vs.90).aspx . Second, since you're connecting to a named instance, which I'm assuming is not the default instance running on the standard port, you need to make sure that the SQL Server Browser service is running, http://technet.microsoft.com/en-us/library/ms165734(v=sql.90).aspx . This is what redirects applications to a non standard port without having to specify the port directly. The reason Management Studio can get past these is that it can connect through named pipes and skip TCP altogether.
See this post as this solved my problem:
These two posts on Using LocalDB with Full IIS should give you more information. Especially the second part seems relevant, but the first one contains some context as well.
Part 1: User Profile
Part 2: Instance Ownership
Credit: IIS connecting to LocalDB
I have a BizTalk Server 2010 installed in windows server 2008 R2. When i publish wcf service through wizard and try to run the service on browser, it returns an error :
The Messaging Engine failed to register the adapter for
"WCF-BasicHttp" for the receive location
"/OrderProcessingDescription/OrderProcessService.svc". Please verify
that the receive location exists, and that the isolated adapter runs
under an account that has access to the BizTalk databases.
Also account used in the application pool is a member of the BizTalk Isolated Host Users group.
One thing which is not installed in Windows Server 2010 is Domain Controller. Please let me know if I need to install it .
please see the following thread to check the actual error:
Link to thread
Answer from thread:
To solve this issue check the application pool security user account
in the IIS. Add that user account into the BizTalk Isolated Host Users
group. Or change the application pool to the pool which user is
already a member of the BizTalk Isolated Host Users Group.
The domain controller feature actually has very little to do with this and the feature is likely not to be installed on your BizTalk server.
Since you are using the publishing wizard:
Ensure that there is an app pool available which is linked to a BTS Isolated host account (you seem to have done this).
Ensure that the app/virtual directory created by the wizard in IIS for the basicHttp endpoint is configured to use this app pool.
Ensure that the corresponding receive port is created, and enabled (look in the BizTalk admin console).
Also ensure that the BTS host process for the receive port is running.
I have a two node BTS2010 group with a separate SQL Server hosting the BTS databases including SSODB; Biz01, Biz02 and Sql01. This environment was configured by a previous employee and I have no documentation available.
There seems to be something not right with the SSO config but I'm not sure how to resolve it.
When I run ssoconfig -status on Biz02 all looks good - it tells me that the SSO Server is Biz02 and the SQL Server is Sql01 plus a load of other stuff. However, when I run the same command on Biz01 I get the message: "Error 0xC0002A0F: Could not contact the SSO server 'Sql01'. Check that SSO is configured and that the SSO service is running on that server'
I'm not clear on what Biz01 is trying to do here - is it trying to reach the EntSSO windows service on Biz02 via an RPC call, before ultimately attempting to retrie config info from Sql01?
I have checked that the ENTSSO service is running on Biz01, Biz02 and that the RPC service is running on each of the three servers.
Can anyone help advise what further steps I can take to determine the root cause of this configuration problem?
Many thanks
Rob.
I'm not sure if you have your servers clustered or not but I've run into something similar before within a cluster. Your SSO name should be your network name and not the individual computers name. Here's an post about the issue I had. Hope it helps.
Reposting my unanswered in technet.microsoft question?
MSDN "ASP.NET Delegation" article tells:
1) "When you configure to use a particular account as the process identity, ASP.NET attempts to delegate that account. If it is a local account that is identical (including password) to a local account on a remote machine, delegation is possible. If such an account does not exist on the remote machine, to the network it appears as the Windows anonymous account (NT AUTHORITY\ANONYMOUS LOGON). In addition, delegation is also possible if the account is a domain account that has access to the remote machine, in which case it uses the domain network identity of that account."
The same frequently repeated story as in case of manually/interactively accessing remote computer (server resource) in workgroup - it is necessary to create local account with the same username, the same password. But why?
If a workgroup Windows client process cannot access resources on server machine without having duplicate of such (local) account on target machine already pre-created,
does it mean that client (process, machine, or user) can access server resources only by/after having logged (opening logon session) into server machine?
Or, how to understand that such access is impossible without having corresponding duplicate local account on server machine?
The same MSDN "ASP.NET Delegation" article tells:
"NetworkService account. It behaves the same as the System account. This account possesses the network credentials associated with the machine account (domainname\machinename) in the domain of which it is a member"
Does not any Windows have accounts ((NT AUTHORITY\NETWORK SERVICE)?
as well as many other common pre-built accounts?
Why are they installed (before any joining to domain) but cannot be used for remote network access and client identification ?
And what is identity used when the process from workgroup Windows under identity ((NT AUTHORITY\NETWORK SERVICE) accesses a remote server?
My related questions:
domained LocalSystem vs. non-domained LocalSystem account in Windows-es ?
how to check group membership of an “NT AUTHORITY\” account ?
Is client LocalSystem (SYSTEM) identified by target/server machine? and in which context?
Window workgroup LocalSystem vs. domain (AD) LocalSystem [closed]
how to better set up machine for development both in workgroup and Windows domain? [closed]
interoperating with Windows domain computer from workrgroup Windows [closed]
the context of local user of AD-joined machine? Is it of domain machine account or of local machine account?
RunAs under domain account from non-AD Windows [closed]
how to better set up machine for development both in workgroup and Windows domain? [closed]
how to share the same domain machine account with multi-boot workgroup Windows setup?
Q1: The same frequently repeated story as in case of manually/interactively accessing remote computer (server resource) in workgroup - it is necessary to create local account with the same username, the same password. But why?
A1: Yes. See A3 below.
Q2: If a workgroup Windows client process cannot access resources on server machine without having duplicate of such (local) account on target machine already pre-created, does it mean that client (process, machine, or user) can access server resources only by/after having logged (opening logon session) into server machine?
A2: Yes - all access by processes on System1 to resources on System2 must be authenticated - except in the rare cases when someone has configured one or more resources (and system policies) on System2 to allow anonymous (i.e. unauthenticated) access. Further, Server2 can only authenticate network requests that present credentials that System2 can verify - either from the local user accounts and passwords on System2, or by contacting a trusted domain controller (if System2 is joined to a domain). System2 doesn't know anything about user accounts or "user contexts" (those special 'accounts' like LocalSystem, Interactive, LocalService which are only ever represented by special hard-coded SIDs) that are only relevant on System1 - which includes any local user account defined on System1, and any of those special SIDs.
Q3: Or, how to understand that such access is impossible without having corresponding duplicate local account on server machine?
A3: The only exception (and it's not an exception, it's a designed-in use case) is when System1 authenticates using a username + password that are the same on System2. What you'll see in the network traffic is that System1's process (currently running e.g. as System1\UserX) will make a request over the network for a resource on System2 (e.g. file share, database object, web page). In that request from System1, is included "the credentials that System1 is trying to use to authenticate" (this is an abstract generalization to get away from describing things specific to any one authentication protocol - just bear with it). Under other circumstances, the account UserX doesn't exist on System2, or it has a different password, so that the authentication attempt fails on System2, and System1's request fails. That is, System2 assumes that UserX must be System2\UserX, and either the account doesn't exist or the password doesn't match.
Under the circumstance where there are matching local accounts, System2 "thinks" that System1 is logging on not with account "System1\UserX" but with "System2\UserX", and since the password matches, the authentication attempt succeeds.
Q4: Does not any Windows have accounts ((NT AUTHORITY\NETWORK SERVICE)?
as well as many other common pre-built accounts?
Why are they installed (before any joining to domain) but cannot be used for remote network access and client identification ?
A4: Remember, NETWORK SERVICE isn't a defined account (you won't find it listed in Local Users and Groups applet) but simply a SID - and if any process includes that SID in its token (depending on the circumstances of how the process with that token is created), then any resource that allows "Network Service" (which really means "any resource that allows the Network Service SID") to access the resource will allow it to pass. Otherwise, Network Service is just a user-friendly abstraction, and unfortunately user friendly usually makes things harder to get to the bottom of how it really works.
You might be able to assign permissions or Privileges to the Network Service SID before the system is joined to the domain, but requests to remote systems will respond very differently for a service running as Network Service depending on if the machine is joined to a domain or not. If joined to a domain, the remote request will usually (on modern Windows versions) attempt the remote authentication using the Domain Computer account for the local system. If not joined to a domain, there will be no credentials sent with the remote request, and the remote system will have to treat it as an anonymous (i.e. unauthenticated) request.
Q5: And what is identity used when the process from workgroup Windows under identity ((NT AUTHORITY\NETWORK SERVICE) accesses a remote server?
A5: As implied in A4, there is no identity that the remote server sees in this scenario.