Posts Tagged ‘windows’

Active Directory Topology Diagrammer

Friday, May 7th, 2010

I may be a bit late in discovering this since it was last published in 2007, but this tool is brilliant. In short, it automatically discovers and diagrams Active Directory domains, OUs, Sites, Exchange organizations, Applications and Servers.

It requires Visio 2003 or 2007 and uses the .NET Framework v2.0 and can be found here

Popularity: 13% [?]

Find All Files Owned By A User – Windows Server 2003

Friday, October 2nd, 2009

If you have quotas enabled on a Windows file server, you may need to locate where all the files a user owns are to work out why their quota just keeps going up and up (and up)…

FSUtil in Windows Server 2003 can do just that (and a lot more). Use the following syntax to find all files owned by a specific user:
fsutil file findbysid <userid> <path>

Userid can be the user’s windows login and the path should be the base directory, it will recurse through sub-directories. Script it up a little and you can get a decent report of quota usage by path.

There is a whole bunch of file server administrative tasks that can be scripted using FSUtil. Very, very good.

Also, this tool (delybown.exe) looks cool, though i haven’t tried it but if it works as advertised would definitely be useful.

Popularity: 35% [?]

Removing An Orphaned DFS Root Target

Wednesday, July 8th, 2009

So, a DFS root target has disappeared. Could be because the server broke bad enough to never be able to be recovered back in to AD or because it was previously a domain controller that has been demoted and decommissioned. In any case, you will get an error from dfsgui saying, “Access is denied” when you try to remove a DFS root target that no longer exists.

Use the dfsutil command to first backup the DFS namespace and then remove the orphaned reference:

1. If not already installed, install the Support Tools for Windows Server 2003

2. Start -> All Programs -> Windows Support Tools -> Command Prompt

3. Backup the DFS namespace, type:

dfsutil /root:<fully_qualified_name> /export:<file>

(<fully_qualified_name> will be the namespace, e.g. \\mydomain\dfsroot and <file>, for example, c:\dfs.txt)

4. Open the file you exported it to, it will show you the reference to the orphaned server and will include a field called ‘Folder’.

5. Remove the reference, type (all on one line):

dfsutil /UnmapFtRoot /Root:<fully_qualified_name>

/Server:<server_name> /Shared:<folder>

(<server_name> is the name of the orphaned server and <folder> is the value from Step 4 above

6. Open or refresh dfsgui and the old root target will be gone.

Be careful to ensure that there is another root target available for the DFS namespace because otherwise the namespace will be deleted.

Popularity: 23% [?]

SFTP server on Windows Server 2003 using OpenSSH

Saturday, June 6th, 2009

This is a quick how-to on setting up a reliable SFTP server on Windows Server 2003. Most of the information for this was gathered from this excellent post [DigitalMediaMinute.com] but this is just a simple and brief explanation. Before getting into the steps, note that this was tested on two separate servers both runing Windows Server 2003 R2 SP2. One was Standard Edition the other Enterprise. One was running IIS (no FTP components installed) not that it should really matter because this is SFTP by default on SSH port 22.

1. Download OpenSSH from here [Sourceforge.net]

2. Unzip it and run the installer on your server.

3. Select all of the default settings (including to install both client and server).

4. Rather than take any chances with spaces, install it to something like <Drive Letter>:\OpenSSH (e.g. D:\OpenSSH)

5. Note that the installer sets up the service and configures it to automatically start but it does NOT start it during or after the install. That wil be done manually later on…

5. The installer will warn that the server is basically not very useful until security is setup

6. Open a command prompt and change directory to your install folder (e.g. D:\OpenSSH)

7. Type the following command to import groups into the SSH server’s group file: mkgroup -l >> .\etc\group

Note: the -l switch specifies local groups. You can use -d switch to specify domain groups. If you just ype mkgroup at the command line, you will see the help / syntax for it’s usage

8. Type the following command to import a specific user in the SSH server’s passwd file: mkpasswd -l -u <username> >> .\etc\passwd

Note: Again the -l switch specifies local objects and the user must exist. If the user name has spaces in it, enclose the name in double quotes. If you just type mkpasswd at the command line, you will see the help / syntax for it’s usage

9. You will need to modify the home directory path for each user and this can be found in the just created .\etc\passwd file. Open the file in something like Wordpad (or do yourself a favour and use Notepad++ [Sourceforge.net]). The second last field in each row is the home directory for the user. To access any drive / path on your server, use this syntax: /cygdrive/<DriveLetter>/path/to/folder(e.g /cygdrive/D/SFTP/MyUsername).

Note: to lock the user to the home folder and it’s contents only, you need to set NTFS permissions so that the user does not have access to browse back up the folder hierarchy.

10. To start the service, from a command prompt type: net start opensshd

11. To test access to the server, use a client like FileZilla [Sourceforge.net] that supports connection to an SFTP serer. Open FileZilla and go to File -> Site Manager… Create a new site pointing to the name or IP address of your server, specify SFTP as the server type, use normal for the logon type and enter the details of the user created above. Press Connect and you should see the connection established to the server on port 22 and you should be placed in the home directory specified above.

I only needed to do this for a single user account which was required for server to server file transfers. I fou that the user had to be an Administrator on the server which was fine for that situation but for user access SFTP it would be a problem. Theortically, the user should just need to exist in the passwd file, provide valid credentials and be granted whatever access is needed via NTFS permissions on the home directory they are pointed at. I didn’t spend time testing it but couldn’t get the user authenticated successfully if they were a member of Users or Power Users even if they had full control on their home folder – only if they were an Administrator.

Hope this helps someone.

Popularity: 15% [?]