Propagating Security Context between Managed Servers
I'm using WLS 8.1 SP2. I have one domain, two managed servers, each on a separate
hardware server. Each managed server hosts a different web application. I want
to authenticate to Web App "A" and be able to invoke Web App "B" (from "A") without
having to re-authenticate. Is this possible via configuration and, if so, how?
Thanks.
"K Northey" <[email protected]> wrote in message
news:[email protected]...
>
I'm using WLS 8.1 SP2. I have one domain, two managed servers, each on aseparate
hardware server. Each managed server hosts a different web application.I want
to authenticate to Web App "A" and be able to invoke Web App "B" (from"A") without
having to re-authenticate. Is this possible via configuration and, if so,how?
>
Does the following do what you want?
http://e-docs.bea.com/wls/docs81/security/thin_client.html#1039551
Multiple Web Applications, Cookies, and Authentication
By default, WebLogic Server assigns the same cookie name (JSESSIONID) to all
Web applications. When you use any type of authentication, all Web
applications that use the same cookie name use a single sign-on for
authentication. Once a user is authenticated, that authentication is valid
for requests to any Web Application that uses the same cookie name. The user
is not prompted again for authentication.
If you want to require separate authentication for a Web application, you
can specify a unique cookie name or cookie path for the Web application.
Specify the cookie name using the CookieName parameter and the cookie path
with the CookiePath parameter, defined in the WebLogic-specific deployment
descriptor weblogic.xml <session-descriptor> element. For more information,
see session-descriptor in Assembling and Configuring Web Applications.
If you want to retain the cookie name and still require independent
authentication for each Web application, you can set the cookie path
parameter (CookiePath) differently for each Web application.
As of Service Pack 1, BEA Systems added a new capability to WebLogic Server
that allows a user to securely access HTTPS resources in a session that was
initiated using HTTP, without loss of session data. To enable this new
feature, add AuthCookieEnabled="true" to the WebServer element in
config.xml:
<WebServer Name="myserver" AuthCookieEnabled="true"/> Setting
AuthCookieEnabled to true causes the WebLogic Server instance to send a new
secure cookie to the browser when authenticating via an HTTPS connection.
Once the secure cookie is set, the session is allowed to access other
security-constrained HTTPS resources only if the cookie is sent from the
browser.
Similar Messages
-
How to pass the security context between different OC4J servers
My problem is the following: it seems that there is no standard J2EE solution in a production environment with more than one J2EE application server products to pass the security context between different J2EE application servers.
I have a distributed application on two different OC4J servers, let's say that we have the web layer (with servlets) deployed on a server instance Server1 and the EJBs deployed on a second OC4J server Server2. If an user is authenticated at the web tier (in Server1) it gets a Principal object. It seems that the same Principal object cannot be used for authorization in the second application server, Server2. This means that in the server Server2 the authentication should be done again. It means that it should be duplicated the mechanism for authentication on Server2 (together with the passwords, users, and so on), thing that is a clear disadvantage of this approach.
Do you know if there is a specific OC4J solution for this approach?
Thank you,
MarinelI have a simmilar issue? Did you succeeded to find a solution?
-
How to share security context between different application ?
Hi all,
I have two applications(ADF faces + BC, JDev 10.1.3.1) deployed into OAS 10.1.3.1.
The two applications are :
1) SalesApp -> main menu page = SalesMenu.jspx
2) ReportApp -> main menu page = ReportMenu.jspx
I want implement security using CustomLogin.
The question is :
How can I share security context between the applications ?
What I mean is, from SalesMenu.jspx there is one menu item to jump into ReportMenu.jspx, and I want user no need to Login again, Login is once and the user is recognized in the two apps. How to achieve that ?
Thank you for your help,
xtantoXtanto,
actually you can't if these are separate J2EE application deployments. The session is not shared and thus the authentication is lost. I heard that OracleAs is planning to implement a feature that allows you to share the session and thus a context between two J2EE deployments. I am not 100 % sure this is the case and will check with OC4J Product Management
Frank -
Security Context Propagation between Managed Servers
I'm using WLS 8.1 SP2. I have one domain, two managed servers, each on a separate
hardware server. Each managed server hosts a different web application. I want
to authenticate to Web App "A" and be able to invoke Web App "B" (from "A") without
having to re-authenticate. Is this possible via configuration and, if so, how?
Thanks.
Frank,
You do not have to do anything to propagate identity between the two
containers. As long as the user is authenticating first..
There have been a number of issues with the propagation, so be sure to stay up
on the service packs.
HTH.
Frank wrote:
How do you propagate security context information from Servlet to
EJBs? I have an web app that uses the container's FORM based authentication.
The servlet resource then calls a session EJB (w/ security contraints
setup). The webapp and the ejbs are bundled into one EAR.
Thanks!--
Tom Mitchell
[email protected]
Very Current Stoneham, MA Weather
http://www.tom.org -
SAML2 between Managed Servers in same Weblogic
Hi,
I need to configure SAML V2 between 2 or more applications deployed in WebLogic 10.3.6 server.
My problem occurs when I try to use application in same weblogic, different managed server.
* App1 call App2 within an iframe.
* When I access App1, logon page works.
* When I access App2 within iframe, credentials was transfered perfectly from App1 to App2.
* When I return to App1, session is ended.
Deploying apps on diferent weblogic all works fine and I can access App1 and App2 normally.
Deploying apps on same weblogic, same managed server, credentials are sharing automatically even SAML not configured.
I can't understand why App1's session was killed when I access App2 in same weblogic and different managed servers.
Does someone can help me?
RegardsI am setting a different cookie for each application. First app show login form and authenticate correctly but when I open second app, credentials was not recnognized.
-
Communicating between Managed Servers
Hi,
I have multiple Managed servers running on the same host, each hosting one web
app on a particular port.
The Admin server runs on port 7001.
Example :
The Managed Server hosting the Session Manager is running on 7100, and the
Managed server hosting the DSLTools is running on port 7200.
The following link works -
http://localhost:7100/sessionmgr/servlet/sessionmgr
Now when I click on DSLTools button on the page displayed by the above link,
it takes me to
http://localhost:7100/dsltools/servlet/dsltools
whereas, I want it to take me to
http://localhost:7200/dsltools/servlet/dsltools
If I type the http://localhost:7200/dsltools/servlet/dsltools
in the web browser, it works.
So, ques is how can I go from Session Manager running on port 7100 to
DSL Tools running on port 7200 ?
I am trying Proxy by path using ProxyServlet, but it doesn't seem to work.
I don't want to hard code the port numbers in the Session Manager servlet
for obvious reasons.
A quick response will be appreciated.
Thank you very much
-Anil VarmaHi Chris,
Thanks for your suggestion. I am going to try you suggestion
and hope somebody responds to it.
Thanks
-Anil
"Chris Chiodo" <[email protected]> wrote:
Hi Anil,
You might consider asking this same question on the
"weblogic.developer.interest.servlet" newsgroup. The people monitoring
that
group would be likely to know the answer to this question.
Thanks
Chris Chiodo
BEA Systems
"Anil Varma" <[email protected]> wrote in message
news:3f1c020e$[email protected]..
Hi,
I have multiple Managed servers running on the same host, each hostingone
web
app on a particular port.
The Admin server runs on port 7001.
Example :
The Managed Server hosting the Session Manager is running on 7100,and the
Managed server hosting the DSLTools is running on port 7200.
The following link works -
http://localhost:7100/sessionmgr/servlet/sessionmgr
Now when I click on DSLTools button on the page displayed by the abovelink,
it takes me to
http://localhost:7100/dsltools/servlet/dsltools
whereas, I want it to take me to
http://localhost:7200/dsltools/servlet/dsltools
If I type the http://localhost:7200/dsltools/servlet/dsltools
in the web browser, it works.
So, ques is how can I go from Session Manager running on port 7100to
DSL Tools running on port 7200 ?
I am trying Proxy by path using ProxyServlet, but it doesn't seem towork.
I don't want to hard code the port numbers in the Session Manager servlet
for obvious reasons.
A quick response will be appreciated.
Thank you very much
-Anil Varma -
SCOM 2012 client movement between Management servers
Hi all,
I know In SCOM 2012 sp1 all management servers are peers , if I have five management servers ( A, B, C, D,E ) and 2 gateway servers ( F, G ) . One client is assigned to A management server , in case if that management server down , to which management servers
or Gateway server that particular client will move any rule.
Thanks,
Sengottuvel MBy default, "the first available management server". There is a black-box algorithm that works behind the scenes in terms of agent failover selection. The only way to control this is to set agent failover lists, and this is only possible via the command
shell (powershell) - but it's relatively easy to do.
Here are a couple interesting articles about the topic:
http://blog.scomskills.com/agent-managementlist-primary-and-failover-configuration/
http://blogs.technet.com/b/jonathanalmquist/archive/2009/11/11/set-failover-management-server-for-gateway-role.aspx
...and there are probably 100 other blog posts talking about the same thing.
Jonathan Almquist | SCOMskills, LLC (http://scomskills.com) -
Hi.
On Windows 2003, I have installed BOXI Edge 3.1 with SAP Integration Kit. My primary and only use of the SAPIK will be for retrieving SAP data for BOXI reports. I DO NOT want to use SAP Authentication. For BOXI, I want to set up only AD Authentication, but because the web.xml files change with the installation of the SAPIK, I have not been successful at setting up AD Authentication. I have modified the web.xml files so that they look like the original web.xml files (without SAPIK).
The AD groups are imported successfully into BOXI. The members of those groups are imported successfully, too. But when a user attempts to login, they get error: An error has occurred propagating the security context between the security server and the client.
I have tried nearly everything to clear this error and there are no Kerberos errors in Wireshark logs on the BOXI server.
Help!
Thank you!
Luis
PS - I asked this question in the SAP Integration Kit forum, and they suggested I ask here, I guess because in the end it may have nothing to do with the SAPIK...Thanks, Tim, for your willingness to help.
The problem is resolved.
I noticed in the Local Security Policy that the right "Log on as a service" displayed only the service account user ID, without the domain identifier - where I expected it to show as "DOMAIN\svcaccount", it only showed "svaccount".
I stopped the Tomcat and SIA services, I removed "svaccount" from the list in "Log on as a service", I reset the account information in the Tomcat and SIA services as "DOMAIN\svcaccount" and saw that change reflected in "Log on as a service" and now AD Authentication works beautifully.
My guess is that it must have been using the local account and not the domain account for running the services.
Next task: SSO...
Wish me luck!
Thanks!
Luis -
Transaction span two WLS managed servers (non-clustering)
(Weblogic 6.1 - non-clustering version)
I have two managed servers configured on a single machine on different
ports, and I am not using clustering weblogic. Assuming I have EJB A
deployed on managed server 1, and EJB B deployed on managed server 2.
I want to have EJB A to invoke EJB B. In EJB A, I guess I will
probably create the InitialContext with the URL of managed server 2,
then do the JNDI look up and call EJB B.
My questions are:
- Can weblogic handle transaction that spans two managed servers
(non-clustering setting)?
- Does weblogic use XA to handle transaction between managed servers?
- Do I need to do any JTA code in order to achieve that (instead of
just letting the EJB container to handle the transaction for me)?
Thanks in advance!
B.L.Hi,
"benson" <[email protected]> wrote in message
news:[email protected]..
(Weblogic 6.1 - non-clustering version)
I have two managed servers configured on a single machine on different
ports, and I am not using clustering weblogic. Assuming I have EJB A
deployed on managed server 1, and EJB B deployed on managed server 2.
I want to have EJB A to invoke EJB B. In EJB A, I guess I will
probably create the InitialContext with the URL of managed server 2,
then do the JNDI look up and call EJB B.
My questions are:
- Can weblogic handle transaction that spans two managed servers
(non-clustering setting)?Yes, it can.
- Does weblogic use XA to handle transaction between managed servers?Yes, it does. Make sure you use TX DataSources. If the servers are connected
to different databases, TX DataSources should be based on connection pools
used XA drivers.
- Do I need to do any JTA code in order to achieve that (instead of
just letting the EJB container to handle the transaction for me)?No, you don't. WebLogic will take care about handling
distributed TXs.
Regards,
Slava Imeshev -
JNDI, EARs and managed servers
I have an EAR file containing a WAR and two EJB JAR files. When I deploy this EAR
onto a server (admin server), assign a target to the 3 modules and run, evertying
is fine.
I now have a scenario where I have added a managed server (so there are two targets
to pick from). I deploy to the admin server as before but I change the target
for the Web module to the new server. This is a typical deployment scenario where
the web container runs on a different server (perhaps in a DMZ) to the EJB container.
Now when I try and run the web app, the servlet fails with a naming exception
- it can't find the EJB in the JNDI tree. Sure enough when I go to the console
and look, the EJBs are only in the JNDI tree on the first server (those they are
targeted to). So the servlet is quite right to complain.
Is then JNDI tree not shared between managed servers? Shouldn't the EJBs be seen
even though they are on separate servers?
If I make the new server a target on the EJBs then it is obviously resolved but
I don't want these remote EJBs on my Web Application server. These are not, and
shouldn't be, clustered servers.
How do I get around this? Do I have to specify the URL_PREFIX of the first server
in my InitialContext properties? This is not very good if I want to move my EJBs
to a different target, I would then have to change the URL_PREFIX again.
I'm using WLS 6.1 sp1I think renaming them in the config.xml IS the easy way. You cannot do it through the console. Truthfully, that is a planning step and you should probably have the correct names before building in order to avoid other issues. Might be easier to just recreate the managed servers.
-
Propagation of ctx between EJB and JSP
Hello,
Does anybody know how to propagate the Security
Context between EJB and JSP so that when I login in my JSP page the user will be after recognized in my EJB system ?
Thanks
Francescotry this...as a test..
take a simple Contact ejb (as simple as you can make it, just a name and email address). In the ejb-jar.xml set up a role, for example, user, and restrict the access to only this role for all methods.
try to access the ejb from a jsp, and you should get the login form identified in your web.xml file.
make sure that the ejb is noted in the web.xml file, also.
this should work...
no try this...identify a role in your web.xml file, (user, for example) and restrict the access to the a particular jsp which is not calling the ejb. IF you navigate to this jsp, you should get the login prompt...
this should work....
now the tough part
in your application.xml create a role with the same name, user. By doing this, you have created a global role, and connect the two together.
Now point your browser to the restricted jsp with no calls to the ejb...you should get the login, so login in.
now navigate to your jsp which is unrestricted, but calls the restricted ejb...
there should now be no login prompt.
This should work. -
Licensing -Security Contexts on ASA5585-X
All,
I have a customer with 2 ASA 5585-X and they are looking at running a total of 20 Security contexts in failover mode on these two firewalls. From a licensing perspective, Can I get 10 security contexts on each of these firewalls and that gives me a cumulative context number of 20.I am not sure though if I will be able to run all 20 contexts in failover mode on both firewalls.
This is the document I am reading but not very clear.
http://www.cisco.com/en/US/docs/security/asa/asa90/license/license_management/license.html#wp1345944
ThanksHi,
If you want to split the 20 Security Contexts between 2 differents ASAs then you are looking at configuring a Active/Active Failover environment.
If you want all Security Contexts to be Active only on one physical ASA at a time (while the other is there to take over when the main one fails) then you are looking at configuring a Active/Standby Failover enviroment.
So in other words
Each units 10 Security Context license will be combined between the units
You can either use 20 Security Contexs on a single physical unit at a time in Active/Standby
OR you can divide the 20 Security Contexts between the 2 Physical ASAs in Active/ActiveFor example 10 Active in ASA1 and 10 Active in ASA2
Also heres a partial quote from the Cisco document
Failover License Requirements and Exceptions
Failover units do not require the same license on each unit.
Older versions of ASA software required that the licenses match on each unit. Starting with Version 8.3(1), you no longer need to install identical licenses. Typically, you buy a license only for the primary unit; for Active/Standby failover, the secondary unit inherits the primary license when it becomes active. If you have licenses on both units, they combine into a single running failover cluster license. How Failover or ASA Cluster Licenses Combine
For failover pairs or ASA clusters, the licenses on each unit are combined into a single running cluster license. If you buy separate licenses for each unit, then the combined license uses the following rules: For example, for failover: You have two ASA 5540 ASAs, one with 20 contexts and the other with 10 contexts; the combined license allows 30 contexts. For Active/Active failover, the contexts are divided between the two units. One unit can use 18 contexts and the other unit can use 12 contexts, for example, for a total of 30.
- Jouni -
Linking JMS Queues between two managed servers
I have an environment setup with an AdminServer and multiple managed servers all under the same domain and on the same cluster. They are all running under the same Instance of weblogic on one Windows Server.
I have two different applications on two managed servers that need to have a JMS Queue be linked between them. Essentially have Server1's 'inbox' link to Server2's 'outbox' and Server2's 'inbox' link to Server2's 'outbox'. Each has their own name for their inbox or outbox.
Server1(inbox)=Server2(outbox)
Server2(inbox)=Server1(outbox)
I've tried using Foreign JNDI Providers, however it doesn't allow me to input two addresses (Server1 and Server2).
Is there another function that would do the same thing?
Thanks!You can make use of Message Bridges between any 3th party JMS provider or SAF (store & forward) if both jms servers are weblogic servers.
Schelstraete Bart
[email protected]
http://www.schelstraete.org
http://www.linkedin.com/in/bschelst
Edited by bschelst at 04/07/2008 1:27 PM -
Current Security Context Not Trusted When Using Linked Server From ABAP
Hello,
I am experiencing a head-scratcher of a problem when trying to use a Linked Server connection to query a remote SQL Server database from our R/3 system. We have had this working just fine for some time, but after migrating to new hardware and upgrading OS, DBMS, and R/3, now we are running into problems.
The target database is a named instance on SQL Server 2000 SP3, Windows 2000 Server. The original source R/3 system was 4.7x2.00, also on SQL Server 2000 (SP4), Windows 2000 Server. I had been using a Linked Server defined via SQL Enterprise Manager (actually defined when the source was on SQL Server 7), which called an alias defined with the Client Network Utility that pointed to the remote named instance. This alias and Linked Server worked great for several years.
Now we have migrated our R/3 system onto new hardware, running Windows Server 2003 SP1 and SQL Server 2005 SP1. The application itself has been upgraded to ECC 6.0. I performed the migration with a homogeneous system copy, and everything has worked just fine. I redefined the Linked Server on the new SQL 2005 installation, this time avoiding the alias and referencing the remote named instance directly, and it tests out just fine using queries from SQL Management Studio. It also tests fine with OSQL called from the R/3 server console, both when logged on as SAPServiceSID with a trusted connection, and with a SQL login as the schema owner (i.e., 'sid' in lowercase). From outside of R/3, I cannot make it fail. It works perfectly.
That all changes when I try to use the Linked Server within an ABAP application, however. The basic code in use is
EXEC SQL.
SET XACT_ABORT ON
DELETE FROM [SERVER\INSTANCE].DATABASE.dbo.TABLE
ENDEXEC.
The only thing different about this code from that before the upgrade/migration is the reference to [SERVER\INSTANCE] which previously used the alias of just SERVER.
The program short dumps with runtime error DBIF_DSQL2_SQL_ERROR, exception CX_SY_NATIVE_SQL_ERROR. The database error code is 15274, and the error text is "Access to the remote server is denied because the current security context is not trusted."
I have set the "trustworthy" property on the R/3 database, I have ensured SAPServiceSID is a member of the sysadmin SQL role, I've even made it a member of the local Administrators group on both source and target servers, and I've done the same with the SQL Server service account (it uses a domain account). I have configured the Distributed Transaction Coordinator on the source (Win2003) system per Microsoft KB 839279 (this fixed problems with remote queries coming the other way from the SQL2000 system), and I've upgraded the system stored procedures on the target (SQL2000) system according to MS KB 906954. I also tried making the schema user a member of the sysadmin role, but naturally that was disastrous, resulting in an instant R/3 crash (don't try this in production!), so I set it back the way it was (default).
What's really strange is no matter how I try this from outside the R/3 system, it works perfectly, but from within R/3 it does not. A search of SAP Notes, SDN forums, SAPFANS, Microsoft's KnowledgeBase, and MSDN Forums has not yielded quite the same problem (although that did lead me to learning about the "trustworthy" database property).
Any insight someone could offer on this thorny problem would be most appreciated.
Best regards,
MattGood news! We have got it to work. However, we did it in something of
a backwards way, and I'm sure you'll laugh when you see how it was done. Also, the solution depends upon the fact that the remote server is still using SQL Server 2000, and so doesn't have quite so many restrictions placed upon it for distributed transactions and Linked Servers as SQL Server 2005 now does.
At the heart of the solution is the fact that the Linked Server coming FROM the remote server TO our SAP system works fine. Finally, coupled with the knowledge that using DBCON on the SAP side to the remote server also does actually provide a connection (see Notes 323151 and 738371), we set up a roundabout way of achieving our goal. In essence, from ABAP, we set up the DBCON connection to the remote server, at which point all the Native SQL commands execute in the context of the remote server. From within that connection, we
reference the tables in SAP via the Linked Server defined on the remote
server, as if SAP were the remote server, selecting data from SAP and inserting it into the remote (but apparently local to this connection) tables.
So, to spell it out, we define a Linked Server on the remote server pointing back to the SAP server as SAPSERV, with a SQL login mapping defined on the remote system pointing back to a SQL login in the SAP database. We also define a connection to the remote server from SAP using DBCON, using that remote SQL login for authentication.
Then, in our ABAP code, we simply do something along the lines of
exec sql.
set connection 'REMOTE'
endexec.
exec sql.
connect to 'REMOTE'
endexec.
exec sql.
insert into REMOTE_TABLE
select * from SAPSERV.SID.sid.SAP_TABLE
endexec.
exec sql.
commit
endexec.
exec sql.
disconnect 'REMOTE'
endexec.
This is, of course, a test program, but it demonstrated that it worked,
and we were able to see that entries were appropriately deleted and inserted in the remote server's table. The actual program for use is a little more complex, in that there are about four different operations at different times, and we had to resolve the fact that the temp table SAP_TABLE was being held in a lock by our program, resulting in a deadly embrace, but our developer was able to work that out, and all is now well.
I don't know if this solution will have applicability to any other customers, but it works for us, for now.
SAPSERV, REMOTE, REMOTE_TABLE, and SAP_TABLE are, of course, placeholder names, not the actual server or table names, so as not to confuse anyone.
Best regards,
Matt -
Have NodeManager start managed servers on machine reboot
Is there any way to have the Node Manager start all the managed servers belonging to a domain when a server reboots?
I know I could create a separate Windows service for each of the managed servers I want running when the server comes on-line, or I could do some fancy scripting at start-up to connect to the Node Manager and have it start the managed servers.
But I was hoping there would be a more elegant way of having the NM start them when it comes on-line.
Ideas appreciated,
dmac.Hi Dmac,
To achieve this in Windows, you must consider the following WLS Components:
1. Node Manager
2. Admin Server
3. Managed Server
Node Manager
For Node Manager, if you want the component to start automatically on boot up, your best option is to create a Windows Service. You may have selected the option to create a service for Node Manager during the WebLogic Server installation. Use Start -> Run -> services.msc from the Start menu to load the Windows Services Manager. If there is no service for Node Manager, use the following steps to create one.
Create a Windows service for Node Manager:
1. WL_HOME\server\bin\installNodeMgrSvc.cmd
2. Verify in Windows Services that a service was created.
Admin Server
For the Admin Server, you can also create a Windows Service. Here are the steps for doing so:
Create a Windows service for the Admin Server
1. Create a text file named %MIDDLEWARE_HOME%\user_projects\domains\<domain name>\servers\AdminServer\security\boot.properties. Add the following lines:
username=weblogic
password=<the weblogic username password>
2. Create a command script called installAdmServer_Service.cmd which you will want to make sure has lines like:
SETLOCAL
set DOMAIN_NAME=<your wls domain>
set USERDOMAIN_HOME=<path to domain> # e.g., C:\middleware\FMW11g\user_projects\domains\ClassicDomain
set SERVER_NAME=AdminServer
set PRODUCTION_MODE=true
cd %USERDOMAIN_HOME%
call %USERDOMAIN_HOME%\bin\setDomainEnv.cmd
call "<your middleware home>\wlserver_10.3\server\bin\installSvc.cmd"
ENDLOCAL
3. For troubleshooting/debugging purposes it is helpful to redirect standard out and error to a text file. Although most information is captured in the AdminServer server log files, you will not see all standard out and error when the server is started via a MS Windows Service (unlike when you start an AdminServer from the command prompt using startWebLogic.cmd). To redirect standard out to a text file, backup and edit installSvc.cmd and change the line at the bottom of the file so it includes the -log parameter, e.g.
"%WL_HOME%\server\bin\beasvc" -install -svcname:"%DOMAIN_NAME%_%SERVER_NAME%" -javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%" -extrapath:"%WL_HOME%\server\bin" -password:"%WLS_PW%" -cmdline:%CMDLINE% -log:"<your middleware home>\user_projects\domains\<your wls domain name>\servers\AdminServer\logs\AdminServer-stdout.txt"
4. Now run "installAdmServer_Service.cmd." The Service should be installed. It will have a name like "beasvc %DOMAIN_NAME%_%SERVER_NAME%" (e.g. beasvc ClassicDomain_AdminServer). The Service "Startup Type" will be "Automatic." Start the Service. The Service will come back fairly quickly to say it is started. The actual time taken for the admin server to start and reach a state of 'RUNNING' will be longer - perhaps two or three minutes. The state of the server can be monitored by reviewing the stdout txt file.
Managed Server
For the Managed Server, you can also create a Windows Service. Here are the steps for doing so:
Create a Windows service for the Managed Server (using wls_forms as an example)
1. Create a text file named %MIDDLEWARE_HOME%\user_projects\domains\<domain name>\servers\WLS_FORMS\security\boot.properties. Add the following lines:
username=weblogic
password=<the weblogic username password e.g manager11g>
2. Create a command script called installWLSFORMS_Service.cmd which has lines like
SETLOCAL
set DOMAIN_NAME=<your wls domain>
set USERDOMAIN_HOME=<path to domain> # e.g. C:\middleware\FMW11g\user_projects\domains\ClassicDomain
set SERVER_NAME=WLS_FORMS
set PRODUCTION_MODE=true
set ADMIN_URL=http://mymachine.mycompany.com:7001
cd %USERDOMAIN_HOME%
call %USERDOMAIN_HOME%\bin\setDomainEnv.cmd
call "<your middleware home>\wlserver_10.3\server\bin\installSvc.cmd"
ENDLOCAL
NOTES:
a. The ADMIN_URL value should reference the AdminServer hostname and listen port.
b. The SERVER_NAME value is case sensitive. For example, if you are creating a MS Windows service for a different managed server such as 'wls_ods1' then the value needs to match the case of the server name otherwise the startup of the server via the MS Windows service will fail.
c. Be careful that there are no trailing spaces after each line in the command file - trailing spaces will cause the managed server to fail at startup. For example a trailing space in the ADMIN_URL value will result in the error
<19-Jan-2010 11:37:58 o'clock GMT> <Error> <EmbeddedLDAP> <BEA-171524> <Cannot determine the Listen address for the Admin server
3. Now run "installWLSFORMS_Service.cmd." The Service should be installed, it will have a name like "beasvc %DOMAIN_NAME%_%SERVER_NAME%" (e.g. beasvc ClassicDomain_WLS_FORMS). The Service "Startup Type" will be "Automatic." Start the Service. The Service will come back fairly quickly to say it is started. The actual time taken for the managed server to start and reach a state of 'RUNNING' will be longer - perhaps two or three minutes. The state of the server can be monitored by reviewing the stdout txt file.
Configuring the Windows service to restart upon failure
As with any Windows Service, it is possible to configure the service to restart itself upon failure. These are standard options available when configuring a Windows Service in the context of Windows Services Manager. However, it is important to understand that Windows Services Manager only monitors the JVM process. If the JVM process fails (shuts down), then Windows Services Manager will attempt to restart it. But there are some scenarios where the Admin Server or Managed Server may go into an unhealthy or failed state but the JVM is still running. The Windows Service will not know to restart the process in these cases, whereas if the Admin Server and Managed Server had been started using Node Manager, Node Manager would recognize such a state and restart the process accordingly. So it may be desirable to start Node Manager with a Windows Service and then start the Admin Server and Managed Servers with Node Manager to take advantage of this monitoring feature. Below you will find one such example of how to do this.
Example of starting the Admin Server and a Managed Server using Node Manager
1. Create a batch script similar to this:
Myscript.cmd
call D:\Product\Oracle\Middleware\user_projects\domains\base_domain\bin\setDomainEnv.cmd
java weblogic.WLST D:\Product\Oracle\Middleware\user_projects\domains\base_domain\ServerStart.py
2. Create a Python script similar to this:
ServerStart.py
nmConnect('weblogic', 'welcome1', '192.168.0.101', '5556', 'base_domain','D:\Product\Oracle\MIDDLE~1\USER_P~1\domains\BASE_D~1','ssl')
nmStart('AdminServer')
connect ('weblogic','welcome1','t3://192.168.0.101:7001')
nmstart('myserver','Server','t3://192.168.0.101:7002')
If you want this to happen automatically on boot up, you can run the script (myscript.cmd) from the Windows Scheduler. You must configure the scheduler to run the script on system startup. This will execute the script without requiring an interactive login to Windows (unattended).
Some Additional Information to Remember
The startup.properties file for the Admin and Managed servers must have "AutoRestart=true." This can be set in the "Health Monitoring" tab for each respective server in the WLS console.
The boot.properties file must be configured and present for each server that you plan to start automatically so that you are not prompted for the user name and password each time. If you are not currently prompted when you start the servers then it is already done.
The nodemanager.properties file must have "StartScriptEnabled=true" and "StartScriptName=StartWeblogic.cmd" in place.
Maybe you are looking for
-
Windows 7 64-Bit AppCrash Itunes 12.1
Problem Event Name: APPCRASH Application Name: iTunes.exe Application Version: 12.1.0.71 Application Timestamp: 54c76235 Fault Module Name: CoreAudioToolbox.dll Fault Module Version: 7.9.9.4 Fault Module Timestamp: 54940ab1 Exception Co
-
I just got a new macbook. Is there any way I can transfer pictures or music to this new mac from my old one?
-
Best security settings for Outdoor P2P with 1300 Bridges
Hello I would like to hear from you otu there what are the best security setting for a P2P bridge outdoor link with two 1310 bridges. (with/without external Radius). any input is very welcome Oliver
-
DDR500 and the Mysterious Vanishing PAT
So. I don't really post here, but I lurk almost daily. Thus I'm pretty much at the end of my tether with these two (apparently unrelated) issues. First, although I have RAM specifically rated at 500 MHZ, whenever I try to change the DDR Frequency fro
-
Can we upgrade IOS in WLC 5508 through CISCO prime?
I have CISCO prime 2.0 and CISCO WLC 5508 HA SSO pair. I would like to upgrade the software code for the WLC HA pair. Can I do through the CISCO prime ...... As per the link :http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-5/High