dinsdag 28 december 2010

FS: Disable the Restore button in Previous Versions

Previous Versions (or, Volume Shadow Copy Service) is a very powerful way of letting users manage their own files in an enterprise environment. One issue however, especially for department-shares, is the possibility to restore a file using Previous Versions. There is no pretty way to disable this using a group policy or something similar, but it IS possible.

By default it is possible for users to restore files. By following the next steps you can turn this off so that only Open and Copy can be used.

  1. Fire up the registry (regedit).
  2. Browse to: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer to turn it on or off for the current user or HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer to turn it off for the local machine. I suggest turning this off on a user basis, so that your IT Administrators can still manage this if needed.
  3. Create a new REG_DWORD with the name NoPreviousVersionsRestore. The value for this entry is 1.
It isn't needed for the users to log off and on again for the setting to be put into place. I suggest putting this in a group policy preference for ease of management.

Hope this helps.


Stefan Hazenbroek

zaterdag 23 oktober 2010

DFS: Manual removal of a DFS Link.

It can happen to everybody. A DFS Link gets deleted in the wrong way by accident, and now it's stale sources are being a burden in your DFSroots directory. This can happen due to errors in namespace replication or unclean shutdowns. The directory cannot be opened or manually deleted, so how can we get rid of this?

When you try to open the directory you'll get the following error:

It makes sense to get this error, because DFS make a sort of junction point on your fileserver to relocate you to the real point. When you try to delete the folder you'll get this error:

When a DFS link gets created, a reparsepoint is created in the DFSroots directory. This is a link to the original directory. Also, see: http://msdn.microsoft.com/en-us/library/aa365503(VS.85).aspx for more information.

This reparsepoint is also what's causing the error. Normally, if you try to open a reparsepoint (like AppData in Windows 7 is), you'll get redirected to the original directory. In the case of DFS this works somewhat different, because the original directory isn't located on the same server.

To fix this we have to take some steps. First, open up Command Prompt and browse to your DFSroots directory. In my case this is C:\DFSroots. Open up your DFS namespace and look at the folder contents. This folder is what's being published when an user accesses your DFS namespace.

Above are the folder contents of the DFSroots folder in my test environment. Top Secret is a stale folder, so I'd like to delete this. Windows contains a tool called fsutil that can help us reach this goal. Type: fsutil reparsepoint query \\. In my case this would be fsutil reparsepoint query "C:\DFSroots\Public\Top Secret". Remember to enclose your query with quotes ("") when your name contains spaces.

The result should look alot like the following:

As you can see within the Tag Value, this reparsepoint is created by/for Microsoft DFS. Now, we're gonna delete this reparsepoint so our view of the namespace will be nice and clean again. Type: fsutil reparsepoint delete \\ and press Enter. Again, mind the quotes.

In this case the rule is: No result is good result. When you get a blank line your command succeeded. When you try to remove something that's not a reparse point you'll get an error looking a lot like the following one:

This means the reparse point is already deleted or you're giving in the wrong directory in your command line.

Hope this helps in keeping your DFS environment clean and tidy.


Stefan Hazenbroek

File Services: Shares not available after a reboot

A short while ago a question was asked on the Technet Forums regarding folders not being shared as expected after a reboot. This specific issue was in regard to BitLocker, but this same issue applies when the folders are being hosted on a volume that's connected through a SAN (Fibre/iSCSI and such)

After being able to answer the question I thought I'd post a short blog article in regard to this issue, because it's a very common issue and not very well documented.

When you reboot your server all shares that are hosted on a SAN, on a BitLocker protected volume or anything other that needs a service in order to ensure it's availability. After restarting the Server service these shares come available, but there are no clear errors in the eventlog that states something is wrong.

The issue is due to the BitLocker (or the service that connects your FC/iSCSI devices) service not being started yet when the Server service is started. When the server service is started, it tries to locate all folders to share and disregard the ones that aren't reachable. Because the service required is started shortly after, you won't notice any apparent issues until you investigate them.

Luckily this issue is quite easily fixed by editing a value in the registry. I'll explain this by showing an example.

1. First, open up services.msc.

When you look at the screenshot below, you'll see the shortname of BitLocker Drive Encryption. Write down this name or save it somewhere, we'll need it later.

2. Open regedit (Start, Run, type: regedit)

Browse to Hkey Local Machine\SYSTEM\CurrentControlSet\LanManServer

When you look in the key you'll see a value called DependsOnService. In my case this value is filled with SamSS and Srv. Open up this value.

As you can see, both services that need to be started in order to start the Server service are SamSS and Srv. Place the cursor after Srv and press Enter. Now type bdesvc (or the name of your required service you located in Step 1) and press Enter again. After filling in the value it should look like this:

Press Ok and reboot your server.

After a reboot your shares will be available directly from boot as they should be. Remember to remove the added service when you disable BitLocker again or remove the disks from SAN, otherwise the Server service won't be able to start.

Hope this helps.


Stefan Hazenbroek

maandag 5 juli 2010

Active Directory: Managed Service Accounts

Windows Server 2008 R2 introduces the new and nifty feature that's called "Managed Service Accounts". A Managed Service Account (from now on I'll call it a MSA) is an account that is tied to a specific computer (for example an IIS Server) and maintains it's own password and SPN's. I can't remember the number of times a service wouldn't start after a reboot of a server because the password for the service had changed but they forgot to change the password at all necessary places.

In this blogpost I will explain the following items:
  1. The requirements for MSA’s
  2. Implementation of MSA's
1. The requirements for MSA's
A MSA depends on the object class msDS-ManagedServiceAccount, for which your schema needs to be at the level of Windows Server 2008 R2. Also, only Windows Server 2008 R2 and Windows 7 support MSA's.

MSA's update the password in the same way as a computer account updates it. By default, the password of a MSA gets updated when the computer account updates it's password. They don't listen to password policies and cannot be locked out or perform interactive logons.

By default all MSA's are created in the CN=Managed Service Accounts,DC=domain,DC=net. When using DSA.MSC and setting it to show "Advanced Features" also displays them.

However, as you see when you open the properties of a MSA, there's nothing to be set apart from the description. This is because all administration of MSA's is done in Powershell.

MSA's automatically maintain their own SPN's but cannot be linked to multiple computers at a time or to a cluster node.

2. Implementation of MSA's For the sake of argument I'll assume you are creating a service account for use with SQL (although this isn't supported by SQL Server yet because of VSS Backups and such). Also, I will use the name SASQL02, but ofcourse you're free to change this to anything you want. For the servername I will use DB01.

At the moment it's not possible to create a MSA that's longer than 15 characters, so stay under this limitation (see http://derek858.blogspot.com/2010/02/server-2008-r2-managed-service-account.html for more information about this)

1. Open Powershell with the AD-Powershell modules loaded (Load this by using import-module ActiveDirectory within Powershell)

2. Create the MSA by using:
New-ADServiceAccount -Name SASQL02 -Enabled $True
3. Now, associate the MSA to a computer account:
Add-ADComputerServiceAccount -Identity DB01 -ServiceAccount SASQL02
4. Logon to the server on which the MSA will be running (in my case DB01). It's necessary to have the following features enabled on the target server:
  • Active Directory Module for Windows Powershell
  • .NET Framework 3.5.1
5. On the server start Powershell with the Active Directory modules loaded.

6. Install the MSA at the server by using:
Install-ADServiceAccount -Identity SASQL02
To install a MSA on a server you will need Local Administrator permissions on the target server and modify permissions on the MSA object in Active Directory.

7. Open up services.msc.

8. Browse to your service and double click on it.

9. Click the tab Log On.

10. Click Browse and type the name of the MSA.

11. The account name is filled in in the following screen. You can see it's a MSA by looking at the dollar sign ($) behind the account name. Also, it's very important that the password field remains empty!

12. Click OK and restart your service. After this moment it's no longer needed to manually change passwords, because your MSA will take care of this.

In a later blogpost I will explain how MSA's are maintained through your environment. In the meantime also check out This post by Ned Pyle.


Stefan Hazenbroek
NOTE: For some reason all images have gone byebye on me. I’ll repost them soon.

dinsdag 11 mei 2010

ConfigMgr: AD Permissions for Domain Join Account

It's a good practise to use a service account for any sort of automated task, and this is no different with SCCM Operating System Deployment.

SCCM OSD has the capability of automatically adding a workstation to the domain during the Task Sequence, so the amount of work that needs to be done by hand is kept to a bare minimum. You use a service account in SCCM that has the permissions to add the computer to the needed OU, but what permissions do you need exactly?

Well, at a minimum you'll need the following permissions:

I hope this helps, I know I'll be back when I need it set again :)


Stefan Hazenbroek

maandag 10 mei 2010

HOWTO: DFS and ABE in Server 2008 and 2008 R2

This blogpost will be quite alot longer than other blogposts, but that’s not an issue in my opinion. Too many times I encounter a situation in which DFS is misconfigured for use with Access-based Enumeration. Some of the times I even encounter an environment in which the fileservers themselves are configured incorrectly. In this blogpost I will explain the following items:

  1. Installing Distributed File System.
  2. Configure a domain-based DFS Namespace.
  3. Creating a DFS Link (Target/Folder Target).
  4. Configuring Access-based Enumeration on the DFS Namespace and the DFS Links.
  5. Setting the correct (NTFS and Share) permissions on the File Share that the DFS Link points to.
  6. Enabling Access-based Enumeration on the File Share on the File Server.

I’ll assume the following items are running as they should/are available, so I’ll not go into them any further:

  • A correctly working Active Directory infrastructure, running at least Windows Server 2008 Domain Functional Level.
  • Familiarity with creating users, groups and manipulating NTFS permissions.
  • You are logged in as a Domain Administrator.
  • The needed groups are available. This means you’ll need a group per DFS Link (or multiple, but that’s up to your design) and a group per folder that should have permissions set. I suggest you never set permissions deeper than the 4th folder, so that would be A\B\C\D and no deeper.

Now, on with the fun stuff.

1. Install Distributed File System

1) Open Server Manager, click Roles and right-click on Roles. Now click Add Roles.


2) Click Next.


3) Select File Services and click Next.


4) Click Next.


5) Select DFS Namespaces and click Next.


6) Choose Create a namespace later using the DFS Management Snap-in in Server Manager and click Next.


7) Click Install.


8) Click Close and reboot the server.


2. Configure a domain-based DFS Namespace.

Now that DFS is up and running we need to create a DFS namespace. This part of the blogpost will explain how you can install a domain-based DFS namespace and configure it for use with Access-based Enumeration.

1) Open the DFS Management Snap-in. This can be found in Start, All Programs, Administrative Tools.


2) Click on Namespaces. Right-click on Namespaces and choose New Namespace.


3) Fill in the servername. In my case this is FS01 and click Next. This is the server that will be running as namespace server. This means in a domain based DFS infrastructure that the server hosts the namespaces, but all configuration items are also available in Active Directory (in CN=DFS-Configuration, CN=System, DC=contoso, DC=com for example). This is still a single point of failure because no other namespace servers are designated.


4) Fill in the name of your namespace and click Edit Settings.


5) If needed, move the local path of the shared folder. You can do this by clicking Browse and choosing a new path. This path will be in the metadata of the DFS infrastructure, or the empty copy of your file server infrastructure when it’s finished. This directory is 0 bytes and will stay this way when it’s managed correctly. Click Use custom permissions and click Customize.


6) Call me paranoid, but I like to keep my permissions granted to an absoluted minimum. Depending on the environment, I give Domain Admins or fileserveradmins Full Control on the share and Domain Users (also dependant on the environment) Change permissions. This way nobody can mess with the permissions except those that should maintain them. Click OK when done adding the needed groups.


7) Click Next.


8) Choose domain-based namespace and toggle Enable Windows Server 2008 Mode to enabled. Click Next.

Important: Access-based Enumeration will not function unless you have your namespace running in Windows Server 2008 mode.


9) Review all your namespace settings and if everything is correct, click Create.


10) Click Close.


3. Create a DFS Link (Target/Folder Target)

A DFS Link can be seen as a shortcut to another file server on which the files themself are hosted. In this part I will explain how to create a DFS Link.

1) Open DFS Namespaces, expand Namespaces and right-click on the namespace created earlier. Click New Folder.


2) Fill in the name of the folder, for this example I used Legal and click Add.


3) Fill in the path to the shared folder on your fileserver or click Browse. Click OK in the Folder Target dialog box and in the Folder dialog box.



4. Configuring Access-based Enumeration on the DFS Namespace and the DFS Links.

Access-based Enumeration is a method to hide files that users don’t have permissions to. As easy as this sounds, this means the NTFS permissions should be setup correctly, otherwise users will still see all files. In this part I will explain how the DFS namespace and the DFS Links can be configured to have Access-based Enumeration in place. I will assume all needed Active Directory Groups are already in place and filled with the users that need permission to this location. For the sake of demonstration I will use the group name DL-Legal-R for the DFS Link Legal.

NOTE! All commands in this section will give a “Done processing this command” notice when the command executed succesfully.

NOTE! Although it is possible to set permissions on the DFS Link (in C:\DFSRoots\…) this is not supported as the permissions will be overwritten by the next Active Directory or registry poll-cycle of DFS. The following method is the only supported method of configuring Access-based Enumeration.

1) Open up Command Prompt (Start, type cmd).

2) Type dfsutil property abde enable <path to the DFS Namespace (in my case \\stefanhazenbroek.net\public) and press enter. This will enable abde (Access-based Directory Enumeration) on the namespace.


3) Type dfsutil property acl reset <path to the DFS Link (in my case \\stefanhazenbroek.net\public\legal) and press enter. This will reset all permissions on the DFS Link to the default.


4) Type dfsutil property acl control <path to the DFS Link (in my case \\stefanhazenbroek.net\public\legal)> protect and press enter.


5) Type dfsutil property acl grant <path to the DFS Link (in my case \\stefanhazenbroek.net\public\legal> <AD Groupname>:R) and press enter. Repeat this step for every group that needs access to the DFS Link. Remember, all groups that are added in here will see the DFS Link, the rest won’t know it exists.


6) Type dfsutil property acl <path to the DFS Link (in my case \\stefanhazenbroek.net\public\legal)> and check if all permissions are set correctly. R stands for Read-only, F stands for Full Control.


5 Setting the correct (NTFS and Share) permissions on the File share the DFS link points to. 

As important as setting the correct permissions on your DFS Links is, it’s nothing compared to setting the correct permissions on your Fileservers. In this example I will explain setting the correct permissions on the fileserver by setting permissions on the root folder (so the folder that your DFS Link points to) and one folder deeper by using Active Directory groups.

1) Go to your fileserver and right-click on the folder that operates as root folder for your DFS Link (this is the same folder as your filled in during step 3.3 in this blogpost. Choose Properties

REMEMBER! The permissions set on this folder should be the same as the permissions set on your DFS Link as set in 4.5 of this blogpost.


2) As you can see, the permissions are still set as they were by default. Click Advanced.


3) Now, click Change Permissions.


4) Untoggle the checkbox at Include inheritable permissions from this object’s parent and click Apply.


5) Click Remove.


6) Click Add.


7) Search for Domain Admins or any other group that will manage the fileserver infrastructure, for example FileServerAdmins and click OK.


8) Toggle Full Control (all other checkboxes will be marked automatically) and click OK.


9) Click OK.


10) Click OK.


11) Click Add.


12) Search for the group you use to give access to the folder.


13) Grant Read & Execute, List Folder Contents and Read permissions to this group and click Advanced.


14) Click Change Permissions.


15) Click Edit.


16) Change Apply To from “This Folder, Subfolders and files” to “This Folder Only” and click OK.


17) As you can see now, the permission is changed from “Read and Execute” to “Special”. Click OK.


18) Click OK again. Now the NTFS permissions for this folder are set up correctly. Repeat the step as needed until all groups that you’ve added in the DFS Link are also added here. Administrative Groups should have “This Folder, Subfolders and Files” set as permission, groups that contain users should have “This Folder Only” permission set.


19) Now we go a folder deeper. For this case I created the folder Legaldocuments with the Active Directory group DL-Legal-Legaldocuments-M and set this as the final folder in my permissions structure. In your case there’ll probably be one or two extra folders before you reach the last one, but in that case you can repeat the earlier steps with new groups. Keep in mind that Domain Admins is already added because we granted inherited permissions to this group.

20) Click Edit.


21) Click Add and add the group you created for this folder, see earlier in this blogpost how this is done. In my case I added the group DL-Legal-Legaldocuments-M and granted Modify permissions. Click OK.


22) Click OK again.


6 Enabling Access-based Enumeration on the File Share on the File Server.

1) Go to Start, Administrative Tools and click on Share and Storage Management.


2) Choose the Share for use with DFS and click Properties on the right-side of the screen (second blue tab at the right).


3) Click Advanced.


4) Toggle Enable access-based enumeration so the checkbox is enabled.


Congratulations, you’ve succesfully setup a simple DFS environment with a file share that has access-based enumeration enabled. It’s up to you to scale this to the enterprise solution you want it to be. Ofcourse, in the case of questions you can always ask them here or by emailing me at stefan<dot>hazenbroek<@>descentes<dot>nl (replace <dot> with . and <@> with @ ofcourse :))

I hope this howto has been of use for you.

Stefan Hazenbroek