I have a WSO2 5.10 server behind an AWS elastic load balancer. Per my original question How can I change the management console port of a wso2 is server using deployment.toml file changes , I modified the template and the server starts and correctly reflects the new management console url in the log file. When I log into it, it also indicates that I have logged in, but the browser simply redirects back to the logon page. Further, the original carbon management url is still active and functional. For example, logon.domain.com is the host name, idp.domain.com is the management url. Both display the carbon management screens, but the idp.domain.com url does not seem to function. No logs other than acknowledging the logon are apparent. This is a multi tenant setup, all of the tenant logons work fine
Any thoughts on diagnosing this would be much appreciated.
I'm following one tutorial to get kie-drools-workbench and kie-server working: https://www.intertech.com/Blog/simple-setup-of-drools-kie-workbench-and-kie-server-in-one-wildfly-instance/
Installed wildfly and downloaded the kie-server-6.4.0.Final-ee7 and kie-drools-wb-distribution-wars-6.4.0.Final-wildfly8 and move them to C:\apps\wildfly-8.2.1.Final\standalone\deployments
Created user jeff with roles admin and developer on wildfly like the tutorial shows.
on CMD start standalone which starts wildfly 8.2.1
got at C:\apps\wildfly-8.2.1.Final\standalone\deployments
- kie drools .war and .deployed
- kie server 64.0 .war and .deployed
Login with jeff user at administration on http://localhost:8080/ and got redirected to http://localhost:9990/console/App.html#home
Under deployments I have the kie-server and kie-drools enabled, how can I access them?
I can land to the kie Workbench with kie server user at http://localhost:8080/kie-drools-wb-distribution-wars-6.4.0.Final-wildfly8/kie-drools-wb.html but I can't land on the kie-server, got forbidden with user jeff or user kieserver at http://localhost:8080/kie-server-6.4.0.Final-ee7/services/rest/server/containers
I don't find why, I login with jeff user but got forbidden and have to restart all to try another user / pass, like kieserver user.
I access kie-workbench, loggin with kieserver user and under deploy -> rule deployments -> remote servers got the kie server link, but the problem is the same, can't access it. forbidden and only have one shot to get the user pass right, or else I have to restart it.
The objective is to work better with drools rules and debug rules the best way, get to check which fact are loaded and which rules are applied to each fact..
Does anyone got the same issue? Or got something like what I need working?
EDIT: I can work with rules on kie-Drools-wb, the question is, do I really need the kie server to start? Because I only need to create rules based one a database.
I think I found the solution.
I don't need to use the server, the server is wildfly and should be running by then, the drools Workbench as explained on the tutorial works and the demo project is the sandbox.
This is only for academic purposes.
I have installed MSMQ and MSMQ AD Integration on a domain controller which also hosts an Exchange server. The whole code has been used successfully on other domain controllers (none of which hosts an Exchange server; I sincerely hope that this is not the reason!).
As required on a domain controller, I have used the following code to allow the network service account to create queues:
SecurityIdentifier sidNetworkService = new System.Security.Principal.SecurityIdentifier("S-1-5-20");
ActiveDirectoryAccessRule NewRule = new ActiveDirectoryAccessRule(sidNetworkService, ActiveDirectoryRights.CreateChild, AccessControlType.Allow, new Guid("9a0dc344-c100-11d1-bbc5-0080c76670c0"), ActiveDirectorySecurityInheritance.All);
de.ObjectSecurity.AddAccessRule(NewRule);
de.CommitChanges();
However, when trying to create/access a public queue, the following error occurs:
A workgroup installation computer does not support the operation.
As described here, I have then uninstalled MSMQ and MSMQ AD Integration, installed it again, but the error is the same.
I verified that MSMQ is installed in Domain Mode by proving that HKLM\Software\Microsoft\MSMQ\Parameters has Workgroup set to REG_DWORD 0x00000001 (1)
So I have had a look into eventvwr.msc and found the following errors:
The Message Queuing service failed to join the computer's domain 'EXCH'. Error 0xc00e0025:
and
Message Queuing was unable to create the msmq (MSMQ Configuration) object in Active Directory Domain Services. Error c00e0025h:
These errors are already described here, but without an accepted solution.
So, does someone have an idea where to find the culprit?
I'm trying to run the CRM Plugin Registration Tool for the first time and I'm getting the following error: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
I'm using the following for the Discovery URL as it's web based CRM: https://dev.crm.dynamics.com.
User name and label are correct.
Thanks in advance.
I had same issue in registering new assembly.
My problem solved in this way:
1- Close current connection in Plugin Registration Tool.
2- Create new connection to server (login again). If you couldn't login, you should reset IIS or Recycle Application Pool or (at least) Restart Server.
Best Regards.
Installed:
SharePoint Server 2010 for Internet Enterprise Beta (x64)
On:
Windows Server 2008 Standard (x64) on 64 bit hardware
Attempts to access the Central Administration console led to IIS returning 503. The service is unavailable
And this error was found in the Application log
The Module DLL 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\isapi\owssvr.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture.
After much ado, the solution turned out to be:
1) Ensure that the enable32BitAppOnWin64 seeting for the "SharePoint Central Administration" app pool is set to False, and the same for the "SharePoint Web Services Root" app pool
2) Edit applicationHost.config:
Change:
<globalModules>
...
...
<add name="SharePoint14Module" image="C:\Program Files\Common
Files\Microsoft Shared\Web Server
Extensions\14\isapi\owssvr.dll"
preCondition="appPoolName=SharePoint
Central Administration v4" />
</globalModules>
To:
<add name="SharePoint14Module" image="C:\Program Files\Common Files\Microsoft
Shared\Web Server Extensions\14\isapi\owssvr.dll" preCondition=
"appPoolName=SharePoint Central Administration v4,bitness64" />
I hope this helps somebody :-)
bitness64 being the magic word here
I got a 503 error because the Application Pools weren't started in IIS for some reason.
1) Ensure that the enable32BitAppOnWin64 setting for the "SharePoint Central Administration" app pool is set to False, and the same for the "SharePoint Web Services Root" app pool
2) Edit applicationHost.config:
bitness64 being the magic word here
I agree with Beytan Kurt.
I had 503 thrown for both the Central Admin site as well as the SharePoint landing page. In both cases the Passwords were expired.
After resetting the password in the AD, and refreshing the Identity, CA worked but the SharePoint landing page threw a 500 error.
It turned out that the .Net Framework Version was set to V4.0. I changed it to V2.0 and it worked.
Remember after each change you need to recycle the appropriate app pool.
Can You Please try this :
Check the web site properties in IIS.
Under home directory tab, check the application pool value
Verify that all SharePoint services are started.
If the application is not started do the following:
I think this error might occur because of changing the service account password.
You may need to change the new password to application pool
1)Click the stopped application pool
2)click advanced settings
3)Identity ->click the user to retype the user
4) Application Pool Identity dialog
5)click set -> manually type the user name and password.
Then restart the server.
It can also happen if your password policy or something else have changed your password in case your appPools are using the the user with changed password.
So, you should update the user password from the advanced settings of your appPool throught "Identity" property.
The reference is here
I had trouble finding the applicationhost.config file. It was in c:\windows\System32\inetsrv\ (Server2008) or the c:\windows\System32\inetsrv\config\ (Server2008r2).
After I changed that setting, I also had to change the way IIS loads the aspnet_filter.dll. Open the IIS Manager, go under "Sites", "SharePoint - 80", in the "IIS" grouping, under the "ISAPI Filters", make sure that all of the "Executable" paths point to ...Microsoft.NET\Framework64\v#.#.####\aspnet_filter.dll. Some of mine were pointed to the \Framework\ (not 64).
You also need to restart the WWW service to reload the new settings.
The selected answer posted here solved one problem, but another is that you'll have to change the app pool to use .Net 2.0.
"SharePoint 2010 uses .NET Framework 3.5, not 4.0. The SharePoint 2010 app pools should be configured as .NET Framework 2.0 using the Integrated Pipeline Mode."
source:
http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/4727f9b4-cc58-4d86-903b-fabed13da0ff
Thanks for sharing this. It helped a lot. The one difference in my applicationHost.config was
<add name="SharePoint14Module" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\isapi\owssvr.dll" preCondition="appPoolName=SharePoint Central Administration v4,bitness64;SharePoint - 80" />
Note the multiple semicolon seperated entries. This is probably because I have a single box install of SPS.
I was having a similar issue with a customer and none of the posted resolutions did the trick. I granted the "Log on as a batch job" permission via the Local Security Policy and that finally made the Central Administration web page come up properly.
Sometimes Web.config of the application ends up in an unconsistent state (duplicate declaration of http handlers, etc)
To check which line in config is causing the error open IIS Manager and try to edit the handler mappings..it will display you the error line if there is such an error in web config.
Strangely such errors do not get logged in Event viewer or ULS
I had the same issue but the password was good and "Log on as batch job" alone was not sufficient.
Check that the IIS application pool identity account or group has both the "Log on as Batch Job" permission AND that it can "impersonate a client after authentication".
To change these settings perform the following steps on the web front end server:
Start>Run type "secpol.msc"
Find: Security
Settings>Local Policies>User Rights assignment
Add user or group to
"Log on as Batch Job"
Check group membership of service account (in
Active Directory) if a particular group is being used for this
purpose.
Find "impersonate a client after authentication" and add the application pool identity
Reboot the server
You should be able to access the site!
Read the user and password in Application -> Advance Settings for Cental Admin application will work.