In PeopleSoft Enterprise, there is an option to enable tracing options from the signon screen. (Tracing options are also accessible after logon from PeopleTools > Utilities > Debug)
I've enabled tracing for SQL statements for debugging purposes. However, I can't figure out where to find my trace logs on the server once the session is complete.
Where are trace logs saved in PeopleSoft when trace flags are enabled?
Typically they are on the Application Server under the directory for your environment.
e.g.
<PS_HOME>/appserv/<domain>/LOGS (quoted from article)
/opt/test/psft/pt/8.53/appserv/prd/LOGS/PSAPPSRV.10742/process_state.txt (quoted from blog entry)
$PS_CFG_HOME/appserv/<DOMAIN>/LOGS (quoted from blog entry)
Related
I'm using the following code in a VB6 DLL (Middleware on an ASP Classic Site) to create a drive mapping to a network share in order to copy files to and fro:
Set ws = CreateObject("WScript.Network")
ws.MapNetworkDrive strDrive, strPath, False, strUser, strPass
At the moment, this works if the share is a normal file server, e.g. \server\share\foo but if I move to a DFS namespace it no longer works, e.g. \mydomain.local\share\foo.
It works in the VB IDE (running as me but using same credentials as the service would) but once compiled and running under the web server the error returned is Error -2147023584 - A specified logon session does not exist. It may already have been terminated.
Most sites I have searched suggest the the local system policy "Network access: Do not allow storage of passwords and credentials for network authentication" be disabled, this is already the case on my machine, I even enabled it then disabled it again to make sure.
Another site suggested connecting to the root node of the DFS first, that didn't work either.
(Windows 7, IIS 7.5)
On II7 we host a WCF/asp.net based API. In order to allow users of a classic asp application to connect to the API we had to publish a version we refer to as "transport". This Transport version is written in asp.net too, it points to the same assembly , its just the security layer is different to allow classic asp to authenticate. Transport level security is used as opposed to message based security.
When using a browser to load the service reference i can loading the svcutil.exe ... WDSL page.
When using my test asp page to call a web method from this reference i get the following returned:
Finished calling Web Service.
Status = Internal Server Error
ResponseText = a:InvalidSecurityAn error occurred when verifying security for the message.
This suggests that the authentication is failing. When testing using asp.net or the application WCF storm to contact the normal API everything works well.
The API was recently migrated , it would appear something has not been setup correctly but i am at a loss to explain what.
I can browse to the svcutil.exe ... WDSL service reference, when selecting it via the browser i get the expect XML response.
The USER NAME and password utilised work when using the non-classic asp publicaiton of the API using the message based secuirty.
Would it be possible to post some troubleshooting tip that may help diagnoise the issue please specifically regarding transport level security fault finding and setup ?
Thank you
Scott
EDITED TO ADD THE FOLLOWING UPDATE:
Attempted to use the Default App Pool and a new App Pool but same problem persists.
My test page error: ResponseText = a:InvalidSecurityAn error occurred when verifying security for the message.
IIS LOG shows:
v3/transport/testclassicasptransportwcfservice.asp ( 200 0 0 ) (i.e iis 200)
/V3/Transport/DeviceService.svc/DeviceService (500 0 0) (i.e iis error 500)
note: virtual dir defined on TRANSPORT and V3. V3 works ok using .net as opposed to classic asp to authenticate.
EVENT LOG:
The Template Persistent Cache initialization failed for Application Pool 'transport' because of the following error: Could not create a Disk Cache Sub-directory for the Application Pool. The data may have additional error codes.
This reference appears to suggest a fix but many of the DIR paths and references in "appcmd" dont exist.
_http://theether.net/kb/100127
REF http://theether.net/kb/100127
load cmd prompt
CD to C:\Windows\System32\inetsrv
enter: appcmd list config -section:system.webServer/asp
the following path is displayed: c:\inetpub\conf\temp\ASP compiled templates
check path exists (it does)
Check if the NETWORK SERVICE has permissions to access "ASP compiled templates" If not from appcmd execute;
icacls "c:\inetpub\conf\temp\ASP Compiled Templates" /grant "NETWORK SERVICE:(OI)(CI)(M)"
should read "sucessfully processed 1 files"
restarted app pool.
THE "InvalidSecurityAn error occurred when verifying security for the message" problem still persists but the "COULD NOT CREATE A DISK CACHE SUB-DIRECORY .... " error from the eventlog is no longer occurring.
Sorry another update. The network service permission change DID NOT resolve the issue , changeing to the DEFAULT APP POOL solved the problem.
Got a lead at last. Examined:
ServiceSecurityAudit set in service behaviour. Ref http://intrepiddeveloper.wordpress.com/2008/08/07/security-event-logging-auditing/#
IIS logs (simply shows the non-specific error 500.)
Fault tracing enabled( also shows error 500).
Custom errors were off
Friendly IE messages were off
Asp client side and server side debugging on
ProcessMon running , no errors.
Web.config httpErrors errorMode="Detailed" /> +
ServiceSecurityAudit found me an "Object reference not set to an instance of an object" so sounds like our app has a bug.
Follow up (17/08/11):
Service Security Audit documented here:
http://intrepiddeveloper.wordpress.com/2008/08/07/security-event-logging-auditing/
Was the key for us to resolve this issue. Uncovered the Object Reference Error which indicated out Business Objects and Data Access dlls were out of alignment. Using CLASSIC ASP to contact the WCF.NET API using TRANSPORT AUTHENTICATION there was abolutely no indication of this error until Service Security Audit was enavled on the behaviour.config file in the WCF deployment.
I've been trying to installing JDeveloper and Weblogic server , and when trying to login as first time as Administrator in console of weblogic ,
The Server give me this error A required MBean Server is disabled which prevents the proper operation of the Weblogic Administration Console Please enable the DomainRuntimeMBean Server and the Edit MBean Server in this domain's configuration.
also I was maked search in "Oracle Forums" i found answer like that :
Also check to make sure there were no errors in the server log during
startup or when you connected to the MBean Server. Sometimes errors can
occur that cause the MBean Server to appear to be disabled. but that answer doesn't help me.
The question is "How to enable **DomainRuntimeMBean**?"
As per this link, try to delete the pending folder within your domain root and restart the server. The default domain has got some corruption in the console settings.
instead of using PC_NAME use URL
e.g. instead of My_PC:7001/console --> use 127.0.0.1:7001/console - Amartya Bandyopadhyay
I'm running IIS5.0 and I am trying to change the ASP.NET process account to my domain user account.
I have followed everything possible here.
When I browse the .svc file (this is a wcf service) I am getting this error:
Server Application Unavailable The
web application you are attempting to
access on this web server is currently
unavailable. Please hit the "Refresh"
button in your web browser to retry
your request.
Administrator Note: An error message
detailing the cause of this specific
request failure can be found in the
application event log of the web
server. Please review this log entry
to discover what caused this error to
occur.
Eventlog says:
aspnet_wp.exe could not be started.
The error code for the failure is
80070522. This error can be caused when the worker process account has
insufficient rights to read the .NET
Framework files. Please ensure that
the .NET Framework is correctly
installed and that the ACLs on the
installation directory allow access to
the configured account.
When I run the client, I get the following error:
The content type text/html;
charset=utf-8 of the response message
does not match the content type of the
binding (application/soap+xml;
charset=utf-8). If using a custom
encoder, be sure that the
IsContentTypeSupported method is
implemented properly. The first 872
bytes of the response were: '
From ASP.NET 2.0 onwards, the correct method to ensure that a user account has the correct rights to run as the worker process identity is to run this command:
aspnet_regiis -ga [account]
You need to run the aspnet_regiis command that matches the ASP.NET version you plan on running:
ASP.NET 2.0 -
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -ga [account]
ASP.NET 4.0 -
%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -ga [account]
If you put your Domain Account under IIS_WPG group, it should ideally work. If it doesn't work, there is a sure shot way of fixing it.
In IIS 6... step 1 is applicable... since you are on IIS 5, ignore step 1
Run it with Local System to begin with. If the applications runs, it means your IIS is configured well and you can proceed with the step 2.
Change the account to your domain account, and ensure that you have put the account in IIS_WPG as well. After that, run the tool called Process Monitor http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Browse the application now. If you still get the error, switch to the Process Monitor and stop capture [menu option].
Search for Access denied and fix it. Link
I have a Windows 2003 server running IIS 6 and have some scripts that do automated setup and creation of websites. They are not working on a new server I cam commissioning (they already work happily on 3 other W2K3 servers). The problem appear to boil down to WMI security on the IIS provider. The ASP code below represents the problem (although it is not the original code that causes the problem - this is a simplified demonstration of the problem).
Set wmiProvider = GetObject("winmgmts:\\.\root\MicrosoftIISv2")
If wmiProvider is Nothing Then
Response.Write "Failed to get WMI provider MicrosoftIISv2<br>"
End If
Response.Write "Querying for IISWebService...<br>"
Set colItems = wmiProvider.ExecQuery("Select * From IISWebServer",,0)
Response.Write "Error: " & Hex(Err.Number) & " (" & Err.Description & ")<br>"
If I run this in my browser, I get an access denied error reported after the ExecQuery call. I have set WMI access for the IUSR_ user from the Root branch all the way down. In fact, I can query for IP address information using the CIMV2 provider quite happily. If I put the IUSR user in the machine admins group it all works, but I don't really want to do that.
This must be a DCOM/WMI security problem, but I can't work out what else there is. Can anyone shed any light?
After reading G. Stoynev's comment asking if any events were logged in the Windows Logs, I checked the event logs on the server to which I'm attempting to access IIS remotely via WMI, and lo and behold I found an event with the following text:
Access to the root\WebAdministration namespace was denied because the namespace is marked with RequiresEncryption but the script or application attempted to connect to this namespace with an authentication level below Pkt_Privacy. Change the authentication level to Pkt_Privacy and run the script or application again.
See the code in this answer to the related SO question c# - "Access is denied" Exception with WMI.
Here's some example C# code that I added that seemed to resolve this issue for me:
ConnectionOptions options = new ConnectionOptions();
options.Authentication = AuthenticationLevel.PacketPrivacy;
ManagementScope managementScope = new ManagementScope(#"\\remote-server\root\WebAdministration", options);
// ...
If this is something that you intend to run as a tool for yourself or your admin (as opposed to the unwashed anonymous masses), here is a way I have used in the past (YMMV):
Set up a new directory in your website (e.g. /SiteCreate) and place your WMI scripts there
Configure a Windows user that has appropriate rights (probably admin in this case but you should use whatever is pertinent to your app)
Turn off the anonymous access to the directory you created in step 1 and then set the security to allow access only to the user you created in step 2 (turn on the authentication for that directory)
Now, when you navigate to that directory in your browser, you should get a login prompt. When you enter the username/password you created in step 2 your script will have the appropriate rights to perform your WMI requests.
Not a DCOM issue, more so a WMI security and encryption issue. Try changing the GetObject moniker to include impersonation and pktPrivacy, eg:
Set wmiProvider = GetObject("winmgmts:{impersonationLevel=impersonate;authenticationLevel=pktPrivacy}!\root\MicrosoftIISv2")
Refer to the follow MS article for more info:
http://msdn.microsoft.com/en-us/library/aa393618(v=vs.85).aspx