Just started working a new job and they have an issue that so far has completely stumped me.
Certain file shares seem to become unavailable intermittently.
\\domainname\FileShares\ returns unavailable, meanwhile all the below work.
\\DC1\FileShares
\\DC2\FileShares
\\DC3\FileShares
\\DC4\FileShares
\\MemberServer\FileShares
I went through all six of our DNS servers and did a lookup on all four of the DC's and domainanme. All returned the expected results.
There are multiple folders in the same namespace and one folder seems to have issues more than the others. The only setting different I found was the the "Override referral ordering was set to be "Last among all targets" I have since unchecked that and the issue persists.
***Edit: Also we only have the one default site in Active Directory Sites and Services.
If anyone has any ideas I would be grateful.
• As you said, you have unchecked the option of ‘Override referral ordering’ in DFS management for domain-based namespace, rather than unchecking it, please select the ‘First among all targets’ option as this will redirect all requests to access a domain-based network share, i.e., ‘\domainname\fileshares\’ always and prioritize them.
• Also, please check the GPO for mapped network drives in ‘User Configuration --> Preferences --> Windows Settings --> Drive Maps’, in that check the mapped network drives and their properties whether their action is set to ‘Replace’ or ‘Update’. If the action is set to ‘Replace’, then change it to ‘Update’ and then let the GPO to be applied to all the systems once again and if it is ‘Update’, then check the path of the network drive stated in it.
• Ensure that the GPO ‘User Configuration --> Administrative Templates --> Shared Folders --> Allow DFS roots to be published --> Enabled’ and ‘Allow shared folders to be published --> Enabled’. Also, please check the time synchronization is accurate between all the sites of the domain.
Please refer this link given below for more information: -
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dfsn-access-failures
Related
Has anyone experienced a situation in Kentico where the admin portal is broken? I've attached an image where you can see the styling is completely missing.
Typically an issue with 1 or many of the following:
In general, installation failed
No permissions granted to the IIS_IUSRS to the directory in the file system
The directory/file does not exist in the file system
Macros need to be resigned due to a change to the CMSHashStringSalt key in the web.config
Improper website set up/configuration in IIS
Caching
UPDATE
Remembered a few other things:
Check the /App_Themes director and make sure you have the following themes
Design
Default
Global
It may be best to copy those three themes from another installation with the same version and hotfix.
I've setup a UNC share for IIS shared config using a specific AD service account and set to FULL CONTROL. I've also exported the config from one IIS server and set-up an additional IIS server to point to the share. When I open the applicationhost.config for example on the UNC share and remove an application pool, I can see the entry also remove in both IIS servers.
So I know:
1) I can export to the share with the specific service account
2) Both IIS servers can read the config when I edit manually
3) However when I remove an app pool from one of the IIS servers through the manager I get the above error.
I've tried using the process monitor utility to see what account is being used to write to the config and it seems it is my own AD user account rather than the shared service account. I know IIS Manager has my username e.g. ROOT\MYNAME logged on, but I wouldn't have thought it would use this to write changes to the shared config. Surely it would use the service account?
Does anyone know how to prevent this error? Why does the shared config and tied service account not come into play when making changes on one of the servers?
So, IMHO, this error is a red herring. I was publishing to a server and got a message saying I was out of space. So, I logged in, realized there was a bit of cruft in extra apps published in IIS, we didn't need. I right clicked and tried to remove one. I got the same error as you.
Having done some manual changes to applicationHost, I thought it "might be me" but it seemed very odd that editing this file would cause such a thing. However, I had recently learned that windows does some funky 32 vs 64bit machinations with this file (google it).
Deciding I had better things to do, I asked our IT to add space to the VM and guess what? I am no able to remove these apps. My guess is that I was at the end of the line on space and the backend management of these special files was not completing and throwing this not-so-helpful exception.
I'm not a 100% about this. For full disclosure, I will add that updates had been applied recently, but I'm pretty confident that this is a possible solution.
I have a site when I tried to apply local staging it's worked fine,but we I tried to connect it through remote server it's not working giving error connection can't be established.Does any one tried it?
This is the configuration with the error message:
This blog post (disclaimer: my own) explains how to do it with https - you can omit long parts of it if you don't want encryption. It also covers 6.0, but the general principle is still the same.
You want to pay special attention to the paragraph Allow access to webservices in that article and check if your publishing server (the "stage") has access to the live server. In general, if this is not on localhost, it requires configuration as mentioned in that article.
As you indicate that you can't connect to your production server from your staging server, please check by opening a browser, running on the staging server and connect it to the production server - go to http://production-server-name:8080/api/axis and validate that you can connect (note: You get the authoritative result for this test only when not accessing localhost as the production system: Do run the browser on the staging system!) - with this test you can eliminate the first chance of your remote system being disallowed. Once this succeeds, you'll need credentials for the production server to be entered on the staging server - the account that you use needs to have permissions to change all the data it needs to change when publishing content (and pages etc.)
The error message you give in the added screenshot can appear when the current user on staging does not have access to the production system (with the credentials used) - verify that you have the same user account that you are using on your staging system (the one that gets the error message from the screenshot) in your production system. Synchronize the passwords of the two.
I your comment you give the information that you're using different version for the staging and the production environment - I don't expect that to work, so this might be the root cause. Test with both systems at the same version.
A couple important points to keep in mind with remote publishing:
If you're not on LDAP (or you have different LDAPs for different environments), you should validate that your user account is exactly the same in both source and target environments. So, if you're on the QA site and you want to remote publish to production, your screen name, email address, and password should all be the same.
Email address is uber important. Depending on which distribution (version) of Liferay you are on, the remote publish code uses your email address to irrespective of whether or not you have portal-ext.properties configured to use screenname.
You should have the Administrator role in on both sides. It may not be required in every scenario, but giving that role out to users that do remote publishing has saved me time and effort debugging why someone's remote publish didn't work. Debugging this process takes a very long time.
If remote publishing is causing you problems (and it probably is or you wouldn't be here), try doing lar file exports / imports. This is important since remote publish failures are not exactly helpful in telling you what failed, they just tell you then failed. Surprisingly, there are often problems in the export process and you can sometimes pinpoint some bad documents or a funky development thing you did using Global scope and portlet preferences that caused your RP to fail. I generally use this order in this situation a) documents and media [exclude thumbnails or your lar file will likely double in size, also exclude ranks if you're not using them] from the wrench icon in the control panel b) web content from the wrench icon in the control panel c) public pages [include data > web content display, but remove all the other data check boxes], include permissions, include categories d) private pages [same options as public pages].
If you already have Administrator role and it's saying you don't have permissions to RP to the remote site, setup your user on the target environment with the "Site Administrator" or "Site Owner" role.
A little late for first and foremost, but anytime you have something that's not working (remote publishing or otherwise), check the logs before you do anything else. The Liferay code base doesn't include a lot of helpful logging, but you do occasionally get a nugget of information that helps you piece together enough to do root cause analysis.
Cheers! HTH
I am having a huge problem with the eventlog on my server. Right let me first of all explain the setup.
I have a domain setup with 2 computers
One computer is running IIS the other is a workstation. The IIS is running Win2k3 the workstation Win XP.
The IIS computer is hosting a website which uses Windows Impersonation and tries to log an entry to the eventlog for a custom log file called MyApp and a custom event source MySource
I have a domain user called MyUser who is just a member of Domain Users.
Single Sign On is working 100% because I can write out the logged in user to the page fine.
When I visit the IIS page from the workstation I get one of the following messages (sometimes I get the first sometimes the second)
1) The handle is invalid
2) Cannot open log for source 'MySource'. You may not have write access.
So to try and fix this I have tried all of the following:
Granted the Everyone user FullControl to C:\windows\system32\config\MyApp.evt file
Granted the everyone user FullControl to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog
In the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\MyApp\CustomSD I appended the following string (A;;0x0002;;;AU), (the reason for this can be read here http://fgheysels.blogspot.com/2008/01/cannot-open-log-for-source-0-on-windows.html)
I am now totally out of ideas of how to fix this. Has anyone else come across this and have you tried anything else.
The error, as you seem to have found already, relates to writing to event sources or creating them. I would suggest you try the following.
You did not indicate if the event source exists in the registry or weather the .evt files ware created by the system or if you put them on the machine, so it is hard to determine at which point you are stuck.
You also did not mention if this works on some developer's machine, in which case you can compare the registries and even create the keys manually if you have to.
Have a look under ...\Eventlog if a key for your log has been created (MyApp?).
Have a look in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\MyApp.
There should be a key called Sources. Does your source appear in here?
If these entries do not exist the error is that your user does not have permissions to create the custom log and source.
In the error message it should indicate a ThreadIdentity parameter, which should indicate which user account it is attempting to use to do this. You can also open the permissions to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog and query the "Effective Permissions" for this particular user to ensure it effectively really has full control.
Try granting full control to the entire directory C:\windows\system32\config\ and not just the .evt file as the system needs to create some additional files here as well.
Lastly you can try and enable anonymous access to the website and run it as the machine/Domain administrator user once so all the keys get created before setting it back to the way you like it. You could also try enabling impersonation in the web.config file to ensure that it is not running without a windows identity. These ones you should all be able to undo once the correct keys and files have been created.
Let us know what you find after this and we can take it further.
Well after many hrs of trying to solve this I appear to have a solution which works.
First of all I had to allow the Authenticated Users group write access to the event log. I advice you backup your registry before continuing.
Run regedit
Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog
Open the subkey which matches the EventLog you are writing to (so I will pick Application)
On the right you will see the registry strings, locate one called CustomSD
Right click and modify it.
Append to the end (A;;0x2;;;AU) (I will explain this later)
Save the changes (I don't know if you need to reboot or not)
So that will mean Authenticated Users can write to the Application event log. I needed to apply one more change.
Open the Domain GPO or local computer GPO
Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights > Assignments > Manage auditing and security log
Go to its Properties window
Select Define these policy settings
Add the Administrator group
Add the Authenticated Users group
Save and do a gpupdate /force for the affected computer.
That is the only way I could get it to allow my website users to write to the event log.
I mentioned in part 1 step 6 I would explain the string we added. Please see this page for more details http://support.microsoft.com/kb/323076
I'm working on a DCOM application with the server and client on two machines, both of which are running WinXP with Service Pack 2. On both machines, I'm logged in with the same username and password.
When the client on one machine calls CoCreateInstanceEx, asking the other machine to start up the server application, it returns E_ACCESSDENIED.
I tried going into the server app's component properties in dcomcnfg and giving full permisions to everyone for everything, but that didn't help.
What do I need to do to allow this call to succeed?
Update: When the server app is running on a Windows 2000 box, I do not get this error; CoCreateInstanceEx returns S_OK.
Right, so if your Authentication level is set to Default. What is the authentication level set to in the Default Settings? Just out of interest. (although the fact that it works to a 2000 box probably makes that redundant)
EDIT:
Also: I seem to remember doing a lot of rebooting when I used to play/work with DCOM so maybe a quick reboot of both machines when you're happy with the dcomcnfg settings wouldn't go amis either.
If the PCs aren't both members of the same domain, you need to also given launch & access permissions to "ANONYMOUS LOGON". "Everyone" does not include this.
Three things to check:
1) Go back to dcomcnfg and make try making sure that not just the access security but also the "launch permissions" section contains the appropriate security users or groups.
2) Ensure that the Authentication Level is set to something else other than "None"
3) Also check that the location on disk that the component is located is actually accessible to the account configured in the security permissions you set.
EDIT:
One more: Are you calling CoInitialiseSecurity() first too? That rings a bell!
EDIT2:
Based on your update: Try dropping the firewalls completely on both XP machines and see if that makes a difference. You may need to let DCOM through explicitly.
What is the flavor of your Windows 2000 box, btw? Professional, Server, Adv Server...
Also, is there a difference between domain membership between the two (one on a domain, the other not, different domains, etc...?)
One more thing - DCOM errors will appear in the System event log at times - especially for object creation - did you check there for clues?
I had the exact same problem.
The problem happens in machines that have XP SP2+ OS or newer.
I solved it using the following steps:
Verify that both client and server computers are on the same domain.
You need to use the same user in both computers, or, if you want to use different users in client and server you need to make sure that both client and server users have privliges on both computers (in particular - make sure that they are members of Distributed COM users group.
open Componenet services MMC (run dcomcnfg).
Go to My Computer->Properties->Default Properties and make sure that Default Impersenation Level is "Identify"
Go to COM Security tab, in both in Access permissions and Launch and activation permissions go to Edit Limits, and add Local and Remote access permissions to the client and server users of your COM application
Make sure that you have a firewall exception in port 135 for your application...
I hope this helps you!