This is every file server admin’s nightmare: hundreds of shares, thousands of folders, hundreds of thousands of files – and custom or not inherited rights on many of them. Terabytes of data that need auditing – e.g. to find customer data, or credit card information. How do you go about accessing all the data in all the trees? What about backups failing because someone removed the System account? Of course you can seize control of the folder by taking ownership and pushing down from a top level – but how do you preserve the existing Access Control Lists? [Read more…]
Testing throughput between two Windows Servers with NT Testing TCP Tool
The NT Testing TCP Tool is a handy little tool for testing the throughput between two servers – and it’s free! It’s available to download here: http://www.microsoft.com/whdc/device/network/TCP_tool.mspx
First, you need to install the MSI on both ends – for the sake of this, say SERVER1 and SERVER2. Once you’ve installed it on the server, navigate to \Program Files\Microsoft Corporation\NT Testing TCP Tool\, you should see a few copies of the tool for different architectures. Locate the correct .exe for you architecture and rename it to ntttcps.exe. Copy this and rename it to ntttcpr.exe – these form the sender and receiver parts of the tool.
[Read more…]
Unable to access admin shares (c$, d$, ADMIN$, IPC$) on Windows Server 2008 in a Workgroup
If you have a Windows Server 2008 box in a workgroup that you require access to one of the admin shares, it can be a little more complicated than with Server 2003. In my case, we had a SQL server on the back end which was trying to access the web server in the DMZ using PSExec.exe to remotely run a process. Executing PSExec and passing the correct credentials failed with “Access is Denied”.
Similarly, when I tried to access the c$, ADMIN$ shares on the server, it would deny me access, and would lock out my admin account when I tried. Creating a separate share would allow me access, but that’s no good for PSExec. To further confuse things, when I accessed the \\server\c$ share from the server, it worked.
Checking the share properties using “net share c$” shows that the settings are all correct, Everyone has FULL access (this is default, it uses NTFS permissions to restrict access):
This issue does not affect domain member servers, I was able to browse to the c$ shares of several Windows Server 2008 servers on the domain.
The problem is caused by UAC and the elevated privileges required to access the administrative shares. This Microsoft KB article (951016) describes the issue in Windows Vista
To better protect those users who are members of the local Administrators group, we implement UAC restrictions on the network. This mechanism helps prevent against "loopback" attacks. This mechanism also helps prevent local malicious software from running remotely with administrative rights.
and the steps to resolve it, open a new PowerShell window as administrator:
New-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -name "LocalAccountTokenFilterPolicy" -value "1" -propertyType dword
A word of caution: this is opening up a security hole and it should only be done with careful consideration of the risks. The need to use PSExec to remotely run a process was an important part of the deployment, however the same result could be achieved using PowerShell remoting. Until it’s tested and we’re ready to deploy that, I’ll be using this method.
Server 2008 – Reporting Services Error The permissions granted to user DOMAIN\USER are insufficient for performing this operation. (rsAccessDenied)
If you install Reporting Services on Windows Server 2008 (RTM or R2) and attempt to verify the installation by opening the http://SERVER/ReportServer site, you may well see the following message:
Reporting Services Error -------------------------------------------------------------------------------- The permissions granted to user 'MCGEOWN\Sam.McGeown' are insufficient for performing this operation. (rsAccessDenied) Get Online Help -------------------------------------------------------------------------------- SQL Server Reporting Services
Additionally, you may be able to access the http://SERVER/Reports site, but will have no permissions:
You may also spend a good while checking DB permissions, IIS configurations, file permissions and so on. And after all that, you may just stumble upon the fact that if you run Internet Explorer as Administrator, it will work as expected.
Event IDs 1030 and 1058 on Server 2003 Domain Controller
I logged onto a production domain controller this morning and checked the event logs to be confronted with this:
Event ID 1030 and 1058 every 5 minutes, looking into the detail for these events I can see its a replication issue for one of the GPOs.
Event Type: Error Event Source: Userenv Event Category: None Event ID: 1030 Date: 29/03/2010 Time: 04:01:29 User: NT AUTHORITY\SYSTEM Computer: DC01 Description: Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
The slightly more informative 1058 showed
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1058
Date: 29/03/2010
Time: 04:06:30
User: NT AUTHORITY\SYSTEM
Computer: DC01
Description:
Windows cannot access the file gpt.ini for GPO CN={3A7AC061-A26C-4154
-8CF5-01D5754E5C2C},CN=Policies,CN=System,DC=DOMAIN,DC=LCL.
The file must be present at the location <\\DOMAIN.LCL\SysVol\DOMAIN.LCL
\Policies\{3A7AC061-A26C-4154-8CF5-01D5754E5C2C}\gpt.ini>. (Access is denied. ).
Group Policy processing aborted.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
There was no visible cause for the errors, DFS had just got it’s knickers in a twist somehow and was not resolving the DFS share for the domain correctly.
The resolution was fairly simple, running the “dfsutil /purgeMUPCache” command seems to have resolved it for now. The /PurgeMUPCache command clears the MUP Cache (duh!) which holds info about DFS and other shares on the client system.
Technet says: “Clears the client MUP cache, preventing confusion about the current provider when such names conflict. Except for a temporary performance hit, this command has no other adverse effects. This command does not affect any DFS metadata. If this command is not run, and the namespace is not accessed, the obsolete cache entry eventually expires.”
There are plenty of other causes for these errors, if your server is multi-homed (multiple NICs) then check that your “public” NIC is at the top of the adaptor bindings.
My DC is now running happily, no 1030 or 1058s.
- 1
- 2
- 3
- …
- 8
- Next Page »