DFS: Properties cannot be set on the namespace server – Access is denied


I ran across a strange problem the other day with DFS. I needed to override the referral ordering for a namespace server, but the change wouldn’t take. I got a status of Error during the Commit changes task. In the detail, it showed Properties cannot be set on the namespace server \\SERVER.domain.local\Share. Access is denied.

Properties cannot be set on the namespace server - Access is denied

This error must be uncommon, because all of the search results are for a similar but differently worded error about changing the properties of a folder and that issue’s resolutions don’t apply here.

I finally figured out the problem, and thought I’d share!

The Root of the Problem

If you looked at the other search results and forum postings and Microsoft KB articles, you probably went around and checked permissions on the target folders. If you’re here by now, then you know that it wasn’t the problem.

Actually, this issue doesn’t live on any of the individual namespace servers. Instead it’s a permissions problem in the Active Directory objects used to store information about the DFS shares. The computer object for each namespace server in a namespace will have some permissions granted on that namespace’s object in AD.

In my case, one of the computers was missing (I suspect that this was a side-effect of a swing migration, as the missing computer was a secondary domain controller that was demoted and then re-promoted after the migration, but that’s another story).

It’s worth noting that this prevented me from changing the referral ordering of another namespace server as well, so even if the ACL looks to be in order for the one you’re trying to change, it’s important to check the ACLs for every namespace server.

The Easy Fix?

You could blow away the whole DFS share and start fresh. That should fix the problem. Of course, if you run into errors deleting it, you might have to forcefully delete it, then use dfsutil.exe to clean up the left over registry entries.

Plus, in my case at least, the DFS share worked just fine. I really didn’t want to bring the share down, or worry about cleaning up leftovers.

The Easy Enough Fix

Since the problem lives in Active Directory, you’ll be making changes to AD itself. We’ll be using ADSI Edit, so hop onto a Domain Controller or a machine with the ADSI Edit RSAT. There’s no need to make this change from a namespace server on the DFS share.

You should also have a complete list of the namespace servers for the share.

Use ADSI Edit to view the DFS configuration

  1. In ADSI Edit, connect to Default naming context.
  2. Browse to DC=ABCD,DC=local > CN=System > CN=Dfs-Configuration
  3. Here, you’ll see a list of your DFS shares: CN=ShareName

    ADSI Edit > CN=System > CN=Dfs-Configuration

  4. Open the Properties of the affected share. In the first tab (Attribute Editor), look for the remoteServerName field.

    fTDFS remoteServerName attribute

    This contains the list of all the namespace servers that AD has listed. Make sure this matches what is shown in the DFS management console. If it doesn’t, you might have bigger problems, and you may need to resort to the “easy” fix.

  5. Now you can switch over to the Security tab. Click the Advanced button so that you see all the entries and the special permissions.

    Advanced Security Settings - Account Unknown

    Looking at the entries for the computer objects (the ones with the $ at the end), we can see that they all have the Read/write all properties access. In this example, you’ll also see a missing object, listed as Account Unknown(S-ID-xxx) with the same access as the other computers, so it’s a good bet that this is the missing one.


Please note that I took these screenshots after I fixed the issue. In the above, STORAGE01$ is not missing, but in the subsequent screens, I use it as the example machine I am adding. I hope it’s not confusing!


Find the missing namespace server and add it back

  1. In the Advanced Security dialog above, click the Add button.
  2. In the Select… dialog, click Object Types… and make sure that Computers is selected. Click OK.
  3. Now choose the computer that was missing from the list, and click OK.

    Select User, Computer, Service Account, or Group Dialog\

  4. Next, you want to give the computer object the  Read all properties and Write all properties Permissions. You can leave the Properties alone or clear them all in advance, as I did. By default, other Permissions may be granted, but only the two listed should be kept.
    Server 2012 Dialog:
    Advanced Permission Entry on Server 2012
    Server 2008 R2 (and earlier) Dialog:
    Advanced Permissions Entry 2008 2003

Wait, Then Test

Once the changes are made, wait until they have had time to replicate to all DCs. It can be difficult to tell which DC you’re hitting when you try to make administrative changes with DFS, so best to wait until all of them have the same information. You could force replication if you prefer.

When you’re sure it’s all synchronized, test it out. I didn’t run into any issues after this.

Unsolved Mysteries

I still don’t know exactly how that computer went missing. As I said, there was some turmoil due to a previous swing migration, but the share was working fine. Stranger still, other DFS shares had the same namespace server missing in the ACLs, yet they had no problem making changes to their properties (like the referral ordering). Seems like they should be broken.

Please let me know if you had success (or not) with this procedure!

Source:

https://www.briantist.com/errors/dfs-properties-cannot-be-set-namespace-server-access-denied/

Advertisements

Measure Boot Performance

Windows 7 Boot process

BIOS/MBR boot process

Server 2008 Boot Process


The classic Windows NT boot process is well known and goes like this.

1. You power on the machine which then goes to the startup BIOS.

2. The Start up Bios loads and performs the Power On Self Test (Post)

3. The startup bios loads the Master Boot Recod of the active partition which then loads up the partition boot record.

4. The boot sector loads NTLDR which then loads the following.

boot.ini

ntdetect.com

ntoskrnl.exe

system registry hive

device drivers

hal.dll

At this point, if all has gone well, you will now be looking at a running Windows NT, XP, Server 2003 machine.

In server 2008, instead of loading NTLDR a new file called bootmgr exists.

Bootmgr then rus the following

Boot Configuration Database (BCD)

Winload.exe

ntoskrnl.exe

system registry hive

device drivers

hal.dll

Then bootmgr passes control to ntoskrnl.exe and the boot sequence is complete.

As can be clearly seen, the traditional boot disk files are of no use in server 2008 as the machine boots in a completely different fashion. Furthermore, when a boot disk is made, it is unique to the server 2008 box it was made for as the BCD file needed for the boot disk contains a system GUID that must match the system upon which it is booting.

Making a boot disk is accomplished in the following fashion.

1. Format a floppy in your Server 2008/Vista machine using the quick option.

2. Open a command prompt with elevated privileges and run the following lines.

MKDIR A:\BOOT

XCOPY /H C:\bootmgr A:\

REG SAVE HKLM\BCD00000000 A:\BOOT\BCD

With this, you have now created the file structure needed for a server 2008 boot disk, and have also copied the files needed for boot.  You will notice that copying the C:\Boot\BCD files directly to disk will fail as these are actually loaded as hives in the registry and locked.  The hive that they reside in HKLM\BCD00000000 is a hidden registry key and cannot be seen from within regedit.exe.

 

(OR)

  1. System is powered on
  2. The CMOS loads the BIOS and then runs POST
  3. Looks for the MBR on the bootable device
  4. Through the MBR the boot sector is located and the BOOTMGR is loaded
  5. BOOTMGR looks for active partition
  6. BOOTMGR reads the BCD file from the \boot directory on the active partition
  7. The BCD (boot configuration database) contains various configuration parameters( this information was previously stored in the boot.ini)
  8. BOOTMGR transfer control to the Windows Loader (winload.exe) or winresume.exe in case the system was hibernated.
  9. Winloader loads drivers that are set to start at boot and then transfers the control to the windows kernel.

Windbg using Error analyze


You can follow the below mentioned steps to get the crash dump:
1. Install WinDbg from http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
2. Launch WinDbg via the shortcut
3. Click File->Open Executable
4. Select Acrobat.exe from “C:\Program Files\Adobe\Acrobat 10.0\Acrobat\Acrobat.exe” and hit “OK”
5. Remember to press “g” and hit enter when you encounter the first breakpoint and then you will see a text “Debuggeee is running” and Acrobat will be launched
6. Open whatever file is it that produces the crash in Acrobat.
7. When you have successfully reproduced the sceanrio causing the crash/freezing of Adobe Acrobat X, enter the below command in the WinDbg terminal

.dump /ma c:\temp.dmp (Hit enter)
8. This will produce the crash dump at C:\ by the name of temp.dmp

Could you please upload the dump (compress the dump using WinZip or likewise) at some site and provide the link for the same. I will have a look at the same.

How to Use the Debug Diagnostic Tool v1.1 (DebugDiag)

%d bloggers like this: