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.
Related
If I'm running multiple web server instances can a client application (like a user using a web browser) be using the different instances or would they be routed to the same instance every time? Let's say they duplicate a tab or open a new tab are those tabs still using the same instance too?
This would be in Azure with IIS/ASP.NET.
When you are using load balance in any environment, you almost always have the option to set session affinity. It means basically, a client who is directed to server 1 on his first request will always be routed to the same server. Azure does provide this flexibility too without question. Here is the documentation with some details on how to do that configuration.
There are a couple of ways how you could configure session affinity. One prominent way is by source IP. So, using a different tab or a different browser instance will not make any difference. Requests from a client machine will always carry the same IP address and hence will go to the same server.
Here is the Powershell sample to set source IP based affinity:
Set-AzureLoadBalancedEndpoint -ServiceName MyService -LBSetName LBSet1 -Protocol TCP -LocalPort 80 -ProbeProtocolTCP -ProbePort 8080 –LoadBalancerDistribution sourceIP
Here is some detail on a more specific scenario that happens when users access a load balanced site from behind a company;s firewall.
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.
My webapplication hosted on windows azure, needs to communicate with TFS Server. When any one login to my web app using live id, I want the logged in user to use my Team foundation server(TFS) credentials -username,password and domain to programatically authenticate and connect to our TFS server and create some work items.
I configured my azure connect for the communication to happen between azure WebRole and TFS server (our TFS is non-azure ).I added both the WebRole and the TFS Server into single Connection Group
In my azureportal ,I can see mywebrole and my TFSServer as connected the machine endpoint is active, and that it refreshes since the last connected updates
.But when I try to run my web application from azure and when it tries to communicate with our TFS server ,its throwing error message saying Error message : Team Foundation services are not available from server eg.,http://xyz-abcxyx-01:8080/tfs/eas/. Technical information (for administrator): The remote name could not be resolved: 'xyz-abcxyx-01'
Any suggestions to resolve this issue ?
You should enable remote desktop on your WebRole and connect to one of your instances. Then, try to ping the IP of your TFS server (not the hostname xyz-abcxyx-01). Maybe this is simply a DNS issue (even though using hostnames works with Windows Azure Connect).
If pinging the IP works, but pinging the hostname doesn't work you have a few options left:
Use the IP instead of the hostname. This won't work if you configured your TFS to use host headers.
Create an elevated startup task to modify the hosts file and map the IP to the hostname. In your code you can keep working with the hostname.
Try to modify the DNS server configured in your WebRole to use the default DNS server + your internal DNS server. But to me this doesn't look like a clean solution.
Anyways, in each solution you'll want to store the IP/hostname in the ServiceConfiguration and make sure your code supports changes to the ServiceConfiguration. This will allow you to change the IP/hostname without having to redeploy.
You should check if TFS server is listening on all network interfaces, include the one created by Azure Connect (start with 2a01). Next try to connect to TFS from a machine on the local LAN, just to make sure it is configured correctly. You don't need to use IP for referring to TFS, DNS name is definitely supported out of box.
I am writing a small c# app to run at startup when a new machine is booted, connected to our corporate network.
I have some code which checks whether a machine account for the machine already exists on the domain, and if so deletes it, prior to joining the machine to the domain.
This works fine on my computer, which already has the trust set up to the domain, but doesn't from a test machine which is not yet joined.
Is there a way round this? Not sure if this is one for Serverfault or Stackoverflow - so hedging my bets!
Yes you can, via LDAP, as long as you can connect to a domain controller via your underlying network transports (ie- TCP/IP). You'll need to bind to Active Directory under the context of a domain user who has at least read access to the directory. You'll also need to specifically call out which domain controller you want to connect to as autodiscovery relies on a domain connection.
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.