by Shijaz Abdulla
on 12.02.2010 at 23:55
If you’re trying to enable File Access in Microsoft Forefront Unified Access Gateway 2010, you might encounter the following error when you try to configure “File Access” from “Admin” menu.
Failed to enumerate domains
Please Check your permissions
Before we troubleshoot this problem, it’s important to understand how the File Access feature in UAG works. The File Access feature is dependent on the Computer Browser service. The Computer Browser service, as we all know, is used when we try to browse the network using “Network Neighborhood”, “My Network Places” or “Network”.
If the file servers are members of a domain, UAG computer has to be a member on that domain, or on a domain that has trust relationship with that domain.
To fix this error,
- Make sure that Network Discovery is enabled on the Internal network connection.
- Open Start > Admin Tools > Services.
- Make sure the Computer Browser service is not disabled.
- Make sure the Computer Browser service is set to Automatic and started.
- Open “Network” on the UAG computer, and see if you can browse other computers on the internal network. If not, troubleshoot accordingly. Once you are able to browse the other computers, then UAG File Access will also work.
If you’re still facing problems,
- take a look at the steps needed in mixed-mode domain environments.
- if there is a firewall between UAG and the file servers, look at this article
by Shijaz Abdulla
on 03.05.2009 at 18:11
This article gives helpful hints on how to successfully interoperate Windows Server with Mac clients. Areas covered are:
- Accessing Windows File Server from Macintosh
- Using Windows DHCP Server with Macintosh clients
- Using Windows DNS with Macintosh clients
- Additional tips for Macintosh (How to Ping, NSLOOKUP, etc)
Many organizations such mainly media and advertising agencies have a mixed environment containing Windows and Macintosh machines. This article explains some of common tasks required when operating Macintosh clients in a Windows Server environment.
Making Windows file shares accessible to Macintosh users
Step 1. Configure the Windows file server
- Create the folder on the file server
- Right-click My Computer, choose Manage.
- On the left pane, expand System Tools > Shared Folders
- Right Click Shared Folders choose Configure File Server for Macintosh.
- On the Configuration tab, under Security, select “Apple ClearText or Microsoft” under Authentication.
- If you would like to allow Macs to save the password, put a check mark next to Allow workstations to save password.
- You can also specify a logon message for connected Mac users if required.
- On the left pane, expand System Tools > Shared Folders > Shares
- Right Click on Shares and choose New > Share.
- Click Next on the welcome screen.
- Put a check mark next to Apple Macintosh users. Click Next.
- On the next screen, choose Use custom share and folder permissions and click Customize.
- Click on the security tab and add users whom you want to give access.
- For read-only access Allow only Read & Execute, List folder contents, Read privileges. For full access, click Modify and Write also.
- Click Next and then click Close.
16. In Computer Management, see that a new MACINTOSH share for your folder has been created. Right click the MACINTOSH share for your folder and select Properties.
17. Under SFM Volume Security, Remove the check mark next to This Volume is read-only.
- Click OK.
Step 2. Configure the Macintosh client
- Goto Apple > Chooser
- Click AppleShare. Click Server IP Address.
- Enter IP address of file server.
- Click Connect.
- Choose Registered user and enter domain username and password. Click Connect.
- Select the folder that you shared on the file server and click Connect. You can also save the password to keychain before clicking connect.
- The icon for the shared location will appear on the desktop.
Enabling Macintosh clients to use Windows DHCP (Mac OS X)
- Go to Apple > Control Panel > TCP/IP
- Select obtain IP addresses through DHCP
- Close the window. Click Save when prompted.
Enabling Macintosh clients to use Windows DHCP (Mac OS 10.x/TIGER)
- Go to Apple > Control Panel > Networks
- Select the Network interface connected to the LAN
- Select TCP/IP.
- Choose DHCP.
Enabling Macintosh clients to use Windows DNS
- Go to Apple > Control Panel > TCP/IP (for Mac OS 10.x, choose Networks > TCP/IP)
- Under Name Servers, specify your DNS Server IP address.
- You can also specify your domain name suffix under Search Domains.
- On your Windows DNS Server, allow both secure & non-secure updates.
- For Mac OS 10.x, you can use “ping” command (without quotes) from the Terminal. (Go > Applications > Terminal)
- For Mac OS 10.x, you can use the “dig” (without quotes) to see the name servers that are being used. In the last four lines of the output, you will see the IP address of the primary DNS server mentioned on a line starting with the word SERVER
by Shijaz Abdulla
on 22.10.2008 at 21:20
Sometimes you cannot delete or rename a file that is currently in use. You might receive an access violation error, or simply a message telling you that your action could not be completed because the file is open in another program.
You may have already come across the Unlocker freeware tool that lets you "unlock" files that are in use by some application.
Here is another way (let’s call it the ‘techie’ way) to unlock files that are in use. It makes use of the Process Explorer tool from Windows SysInternals.
- Download the Process Explorer tool. Execute procexp.exe
- Choose Find > Find Handle or DLL option
- Type the name of the file you want to unlock and hit Search.
- The process EXE locking the file and the path to the file are listed. Double click on the result.
- The file handle will be highlighted. Right-click on it and choose Close Handle.
Your file is now unlocked and can now be deleted, moved or renamed.
A little disclaimer here, closing handles might cause data inconsistency, loss and/or other undesirable effects. Make sure you understand what you’re doing before you do it.
by Shijaz Abdulla
on 07.10.2008 at 07:46
Distributed File System (DFS) that comes with Windows Server 2003 and Windows Server 2003 R2 is not cluster-aware.
You will not be able to add the virtual name of a file server cluster while defining a namespace server. Even if you try to get away by typing in the virtual name without browsing for it, you will most likely end up with an error:
The object identifier does not represent a valid object.
This means you cannot replicate between a file server cluster and a standalone file server (or another file server cluster).
To sum up, Microsoft DFS Replication service is not cluster aware and hence you cannot replicate data stored on shared storage. Even if you manage to do it, remember that storing replicated folders on a shared storage is NOT supported.
by Shijaz Abdulla
on 07.01.2008 at 10:27
Most administrators think the best way to back up user’s Outlook PST files is to store it on a network share and let Outlook connect to it from a file share or mapped drive. This way all PST files are on a central location and backup is easy. Sounds like a nice strategy, doesn’t it?
Don’t ever do it. Ever.
Why? Here are two good reasons:
1. This can cause your file server to hang!
Believe it or not, the way Outlook access the PST files is aggressive. Let’s take an example. Early in the morning, some user sends out an email to 500 employees in your company. Some of these 500 users may need to extend their PST file in order to accomodate the incoming email message. To extend a PST, an extra allocation on the disk has to be made via NTFS. During this process, the whole volume is locked out while free space is allocated and the Master File Table (MFT) is updated. While this is happening for one user, all I/O for the other 499 users is on hold. This includes other users’ PST files as well as ordinary file shares on the same volume!
Now imagine if each user had multiple PST files! The disks get overloaded and the server suffers from serious performance issues. The queues for writing data to disk build up. This ultimately amounts to a server hang or PagedPool memory depletion!
2. It’s not supported
In case you were thinking – NO, it isn’t supported by Microsoft for you to store PST files on network shares. This restriction is not new, and has been around since Microsoft Exchange 4.0. This means storing PST files on a network share is an unsupported configuration and you will not receive support from Microsoft. For details, see MSKB article 297019
Storing PST files on the file server is a very common mistake that administrators make and I thought it would be helpful if I posted it here.