When a user cannot see the content of a particular public folder, even if he/she is an owner of it and none of the steps from the article above helps, try this

1. Make only one user an owner of a public folder with synchronization issues
2. Turn all other Owners into Publishing Editors
3. Run the user’s Outlook as follows

Outlook /cleanviews

4. Be aware that the user will lose all the views created in Outlook

“Logon unsuccessful: Windows is unable to log you on”

KB947232 can help to resolve the issue. The fix taken from the article is below

1.  Click Start, type regedit in the Start Search box, and then press ENTER.
2.  Locate and then click the following registry subkey:  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
3. On the Edit menu, point to New, and then click DWORD (32-bit) Value.
4. Type LocalAccountTokenFilterPolicy to name the new entry, and then press ENTER.
5. Right-click LocalAccountTokenFilterPolicy, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Exit Registry Editor.

The LocalAccountTokenFilterPolicy entry in the registry can have a value of 0 or 1. These values set the behavior of the entry as follows:

0 = build a filtered token
This is the default value. The administrator credentials are removed. These credentials are required for remote administration of the print drivers.

1 = build an elevated token
This value enables the remote administration of the print drivers on a server within a workgroup.

As Microsoft says in KB Article:

“This problem occurs because the Kerberos token that is generated during authentication is more than the fixed maximum size”

In order to fix that, just create a DWORD registry value

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
MaxTokenSize=dword:65536

and restart the computer

SMB Tuning for XenApp and File Servers on Windows Server 2008

http://blogs.citrix.com/2010/10/21/smb-tuning-for-xenapp-and-file-servers-on-windows-server-2008/
By Dan Allen · Published October 21, 2010

I have received a lot of questions from customers lately on whether there is a need to tune Windows Server 2008 file servers, especially if the client machines connecting to them are capable of using SMB 2.0, which includes Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. Unfortunately, there is not much information out there on this topic, so I decided to do a little research and testing for myself.

The SMB 1.0 Problem

To begin, it is important to understand the SMB 1.0 limitation that has been present since we first started implementing Terminal Server deployments back in the good old days of NT and MetaFrame. There have already been a lot of good SMB tuning articles out there that discuss this in detail, so I will not go into too much of an extensive discussion here, but I will summarize.

When a client computer using SMB 1.0 (NT 4.0, 2000, XP, 2003, etc…) attempts to connect to a Windows file server, it will query the file server and ask how many concurrent network (SMB) commands it can have submitted and open simultaneously. The file server will respond with a number and the network redirector on the client computer will limit itself to the number provided by the file server. The number that the file server provides is controlled by the SMB value for Max Mpx Count, which is set by the following registry entry on Windows file servers:

“HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\MaxMpxCt”

By default, this value does not exist on a Windows Server. If it does not exist, the Operating System uses a default value of 50.

This means that an individual client computer will not be able to have more than 50 simultaneous SMB commands to the file server. An SMB command can be anything from a directory listing, file creation, deletion, ACL manipulation, etc… basically, any kind of file or directory access.

The 50 command limitation quickly becomes a problem on a Terminal Server because there is only one redirector that is shared by all users on the server. In a typical Terminal Server environment, often users will all connect to the same file server for home directories, roaming profiles and redirected folders. This means that each user could easily be generating multiple SMB commands to a single file server. Once you start loading 50+ users on the server, you can easily have more than 50 outstanding SMB commands that need to be serviced, especially if folder redirection is being used. Since only 50 get serviced at one time, the rest of the commands begin to queue up and wait for servicing. This can cause poor performance or even application failures as applications make file requests that time out waiting to be serviced.

A workstation or SMB Client may make a request to have more than 50 SMB commands simultaneously open to a file server; however, if the file server has not been tuned, the client will not use more than the Max Mpx Count returned by the file server. The maximum number of simultaneous requests that a workstation will attempt to use is controlled by the Maximum Commands SMB setting defined by the following registry entry on the client:

“HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\MaxCmds”

By default this value is also 50 if it is not defined. So to properly tune an environment for maximum density of Terminal Server/XenApp users, you must add the MaxCmds key to all Terminal Serves and the MaxMpxCt key to all file servers. We have typically recommended increasing these entries to a decimal value of 2048.

Microsoft has a good article (324446) that has been around since Windows 2000 that discusses this issue and recommends the follow registry keys that should be implemented on file servers being accessed by Terminal Servers:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

“MaxWorkItems”=dword:00002000 (decimal 8192)
“MaxMpxCt”=dword:00000800 (decimal 2048)
“MaxRawWorkItems”=dword:00000200 (decimal 512)
“MaxFreeConnections”=dword:00000064 (decimal 100)
“MinFreeConnections”=dword:00000020 (decimal 32)

It is also important to note that this issue and these registry keys are fully applicable to Terminal Servers and File Servers running the x64 edition of Window Server 2003. This is not a 32-bit problem, but rather an SMB problem.

In addition to the above registry tuning, there was another SMB client fix which reduces the SMB chatter and SMB commands that are opened from a client to a file server. This registry setting is one that we recommend be implemented on all XenApp Servers:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer

“NoRemoteRecursiveEvents”=dword:00000001
You can verify whether or not your system has excessive SMB commands being queued by reviewing the following performance monitor counter on your XenApp servers: Redirector/Current Commands. If this counter gets close to 50 and you have not tuned your file servers, then you definitely have a problem.

Here are some Microsoft articles for reference:

http://support.microsoft.com/kb/324446
http://support.microsoft.com/kb/232476
http://support.microsoft.com/kb/810886
http://support.microsoft.com/kb/831129

.Reg file

I have just compiled the settings that Dan mentioned in his article into one, ready-to-use .reg file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters]
“MaxCmds”=dword:00000800

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters]
“MaxWorkItems”=dword:00002000
“MaxMpxCt”=dword:00000800
“MaxRawWorkItems”=dword:00000200
“MaxFreeConnections”=dword:00000064
“MinFreeConnections”=dword:00000020

The solution is described in details in this Microsoft article: Certain Administrative Templates from the Windows XP Security Guide may prevent you from starting the Windows Firewall service in Windows XP Service Pack 2 (http://support.microsoft.com/kb/892199)

Microsoft offers two solutions for this issue, I have successfully implemented the one below

• Click Start, click Run, in the Open box, type regedit, and then click OK.
• Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Security

• Delete the Security registry subkey, if it exists.
• Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{ce166e40-1e72-45b9-94c9-3b2050e8f180}

• On the File menu, click Export.
• In the File name box, type C:\reg_AppID_CLSID.reg, and then click Save to save the registry file.
• Delete the {ce166e40-1e72-45b9-94c9-3b2050e8f180} registry subkey.
• Exit Registry Editor
• Restart the computer.

Note: It is important to delete the Security registry subkey if this subkey exists. This guarantees that the default security descriptor is used for starting Windows Firewall when the computer is restarted.

In order to set it up, just run this command:

bcdedit /set IncreaseUserVa 3072

and restart the computer.

This command removes the option

bcdedit /deletevalue IncreaseUserVa

Before version 4, VMware ESX used Net-SNMP as SNMP agent. Now it has its own agent which can be used with or without Net-SNMP. Usually, Net-SNMP is required by monitoring software. In this case it can be set up to pass any incoming requests, related to VMware, to VMware SNMP agent to get access to VMware MIBs.

This article describes how to configure both agents. If you do not need to use VMware SNMP agent, configure Net‐SNMP as you would do on a typical Linux host. If you do not need to use Net-SNMP agent, configure VMware SNMP agent to use UDP port 161 instead of 171, shown in this document

Some information can be also found here: http://www.vmware.com/pdf/vsp_4_snmp_config.pdf

Net-SNMP Configuration

Log on to the service console on the ESX host

Stop the snmpd service

service snmpd stop

Go to /etc/snmp and make a copy of the original configuration file to create a backup

cd /etc/snmp
cp -p snmpd.conf orig-snmpd.conf

Modify the snmpd.conf file and add the following:

rocommunity <community name> <ip address of trap destination 1>
rocommunity <community name> <ip address of trap destination 2>

Remove these lines:

#       sec.name  source          community
com2sec notConfigUser  default       public
…
####
# Second, map the security name into a group name:
#       groupName      securityModel securityName
group   notConfigGroup v1           notConfigUser
group   notConfigGroup v2c           notConfigUser

Locate the system contact information section. Update the syslocation and syscontact fields:

syslocation Toronto, ON, CA
syscontact  esxgroup@esx.ca

Add the following line at the end of the file.

proxy -v 1 -c <community name> udp:127.0.0.1:171 .1.3.6.1.4.1.6876

Here -v 1 reports the Net-SNMP version, -c specifies the community string for Net-SNMP, udp:127.0.0.1:171 specifies the local host IP address and the UDP port number for the VMware SNMP agent.  This port number can be any unused UDP port. The port number must be the same as the one for the VMware SNMP agent. 1.3.6.1.4.1.6876 is the object identifier of the VMware MIBs. Net-SNMP will pass all the requests under this OID to the agent listening on the specified port and on the specified host. In our case it is a local host on UDP port 171.

Add another line

trapsink < ip address of trap destination> <community name>

The trapsink specification is required to send traps defined in the proprietary MIBs (such as VMware)

Save the file and exit

To start the Net-SNMP service when the ESX host boots, use these commands

chkconfig snmpd on
chkconfig –list snmpd
snmpd           0:on   1:on    2:on    3:on    4:on   5:on    6:on

Start the Net-SNMP service

service snmpd start

Note: If any Net-SNMP has any dependant services (such as the DELL Server Administrator (OMSA)), they should be also restarted

Check the status of the snmpd service

service snmpd status

snmpd (pid  13728) is running…

Now you should be able to use snmpwalk off of any machine to check out the SNMP communication

VMware SNMP Agent Configuration

VMware SNMP agent can be configured with three ways: by using VMware Perl scripts (vicfg-snmp.pl), by using VMware PowerCLI (PowerShell extension for VMware) or by editing manually the agent configuration file via the service console. We will do all three, using UDP 171 that we configured for Net-SNMP proxy

Note: VMware recommends using the vicfg-snmp.pl or PowerCLI commands to change the configuration instead of editing the file itself

Perl Script

If you have installed VMware vSphere CLI, you can find the scripts in this location:

C:\Program Files\VMware\VMware vSphere CLI\bin

Run

vicfg-snmp.pl –help

…to see all the parameters

Running this Perl script you will be asked to enter user name and password to connect to the service console, unless you use –username and –password parameters

vicfg-snmp.pl –server <ESX host ip address> –username root –password <password> –show
Current SNMP agent settings:
Enabled  : 0
UDP port : 161
Communities :
Notification targets :

Add community

vicfg-snmp.pl –server <ESX host ip address> –username root –password <password> –communities <community string>
Changing community list to: …
Complete.

Change port number

vicfg-snmp.pl –server <ESX host ip address> –username root –password <password> –port 171
Changing port to: 171…
Complete.

Add trap destinations

vicfg-snmp.pl –server <ESX host ip address> –username root –password <password> –targets <ip address of trap destination>@162/<community string>
Changing notification(trap) targets list to:…
Complete.

Enable agent and check the configuration

vicfg-snmp.pl –server <ESX host ip address> –username root –password <password> –enable
Enabling agent…
Complete.
vicfg-snmp.pl –server <ESX host ip address> –username root –password <password> –show
Current SNMP agent settings:
Enabled  : 1
UDP port : 171
Communities :
<community string>
Notification targets :
<ip address of trap destination>@162/<community string>

VMware PowerCLI

It is very similar to the VMware vSphere CLI Perl script

Connect to ESX host

Connect-VIServer <host ip address>
WARNING: There were one or more problems with the server certificate:
* The X509 chain could not be built up to the root certificate.
* The certificate’s CN name does not match the passed value.

Name                           Port  User
—-                           —-  —-
<host ip address>                  443   root

Check configuration and get it to the $SNMPConf variable

Get-VMHostSNMP
Enabled   Port ReadOnly Communities
——-   —- ——————–
False      161 {}

$SNMPConf = Get-VMHostSNMP

Clear communities if you have any

Set-VMHostSnmp -HostSnmp $SNMPConf -ReadOnlyCommunity @()
Enabled   Port ReadOnly Communities
——-   —- ——————–
False      161 {}

If you try to enable it now, you will get an error message, because UDP 161 is already in use by Net-SNMP

Set-VMHostSnmp -HostSnmp $SNMPConf -Enabled:$True
Set-VMHostSnmp : 17/08/2011 2:32:56 PM    Set-VMHostSnmp        A general system error occurred: Bind socket(af=2) failed, reason: 98, Address already in use

Add community

Set-VMHostSnmp -HostSnmp $SNMPConf -ReadOnlyCommunity <community name>
Enabled   Port ReadOnly Communities
——-   —- ——————–
False      161 {<community name>}

Change port number

Set-VMHostSnmp -HostSnmp $SNMPConf –Port 171
Enabled   Port ReadOnly Communities
——-   —- ——————–
False      171 {<community name>}

Add trap destinations

Set-VMHostSnmp -HostSnmp $SNMPConf -AddTarget -TargetCommunity <community name> -TargetHost <ip address of trap destination>
Enabled   Port ReadOnly Communities
——-   —- ——————–
False      171 {<community name>}

Enable agent

Set-VMHostSnmp -HostSnmp $SNMPConf -Enabled:$True
Enabled   Port ReadOnly Communities
——-   —- ——————–
True       171 {<community name>}

Test the configuration

Test-VMHostSnmp -HostSnmp $SNMPConf
Test-VMHostSnmp : 19/08/2011 4:22:29 PM    Test-VMHostSnmp        A general system error occurred: Connection refused
At line:1 char:16
+ Test-VMHostSnmp <<<<  -HostSnmp $SNMPConf
+ CategoryInfo          : NotSpecified: (:) [Test-VMHostSnmp], SystemError
+ FullyQualifiedErrorId : Client20_SystemManagementServiceImpl_TestVmHostSnmp_ViError,
VMware.VimAutomation.ViCore.Cmdlets.Commands.Host.TestVmHostSnmp

Connection refused? It happened because the current machine has not been added as a trap destination

Add it and test again

Service Console

VMware SNMP agent configuration is stored in the snmp.xml file.

Log on to the service console on the ESX host

Stop the snmpd service

service snmpd stop

Go to /etc/vmware and make a copy of the original configuration file to create a backup

cd /etc/vmware
cp -p snmp.xml orig-snmp.xml

Modify the snmp.xml file:

<config>
<snmpSettings>
<enable>true</enable>
<communities>public</communities>
<targets>127.0.0.1@162/public</targets>
<port>171</port>
</snmpSettings>
</config>

As you can see the file contains the parameters accessible via PowerCLI or vSphere CLI.

Restart mgmt-vmware service

service mgmt-vmware restart

Start the Net-SNMP service

service snmpd start

ERROR: You do not have the Backup and Restore Files user rights.

Yes, if I right click on the batch file and select Run As Administrator, everything works fine. My goal has been to run this batch file from the command line without user interaction at all. At the same time I have needed not to compromise security

RunAs does not help at all. In order to get the privileges elevated the Administrator user has to be used, but this user is disabled by default and I do not want to enable it.

I have tried to change batch file properties and set up Run This Program As an Administrator, but this checkbox has been disabled. I have done this for Robocopy.exe, but it makes situation even worse: UAC asks its question every time the batch file runs robocopy.

Finally, I have found the solution

I have created a scheduled task called RunBatch to run my batch file. I have not set up any schedule for it; I have checked the Run on highest privileges box on General tab and saved the task.

The command

SCHTASKS /run /tn RunBatch

runs the job with elevated privileges and without asking any question

ManagedBy is just one of the attributes of a group object, so it is pretty easy to change it. The Manager can update membership list checkbox, however, is not a property. It represents the security permission on the group object, called WriteMembers. The checkbox is in fact a logical statement

Checkbox = (ManagedBy_Object_Permissions = WriteMembers)

Even if the ManagedBy object has full access to the group and can do whatever it wants to, the checkbox appears only if only WriteMembers permission is set up to “Allow”

Of course, PowerShell can help us to set up everything. The script is short, but has two interesting parts:

1. The ManagedBy attribute requires a distinguished name, but the ACL uses SAM account name. So, the script converts one name to another one.
2. System.DirectoryServices.ActiveDirectoryAccessRule constructor (http://msdn.microsoft.com/en-us/library/system.directoryservices.activedirectoryaccessrule.aspx) can be overloaded

One of six variants is

ActiveDirectoryAccessRule(IdentityReference, ActiveDirectoryRights, AccessControlType, ActiveDirectorySecurityInheritance)

And another one is

ActiveDirectoryAccessRule(IdentityReference, ActiveDirectoryRights, AccessControlType, Guid)

If we use WriteMemberGUID as a type of string, the constractor assumes that this is the first variant and will raise an error.

 $NewAccessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($ManagedByAccountObject,$WritePropertiesObject,$AllowObject,’BF9679C0-0DE6-11D0-A285-00AA003049E2′)

 New-Object : Cannot convert argument “3″, with value: “BF9679C0-0DE6-11D0-A285-00AA003049E2″, for “ActiveDirectoryAccessRule” to type “System.DirectoryServices.ActiveDirectorySecurityInheritance”: “Cannot convert value “BF9679C0-0DE6-11D0-A285-00AA003049E2″ to type “System.DirectoryServices.ActiveDirectorySecurityInheritance” due to invalid enumeration values. Specify one of the following enumeration values and try again. The possible enumeration values are “None, All,Descendents, SelfAndChildren, Children”.”

It suggests using values for inheritance and if we do so, it will set up entire Write permission as Allow, not just WriteMembers. The managedBy object will have permissions to change the group members, but as it has been noticed above, the checkbox will not be checked. To avoid this situation, just define GUID as the [GUID] type.

So, the script looks like this. The key statements are bold

#### Our variables
$ManagedByName = “CN=Karmadanov\, Andrew,OU=Users,OU=IT,DC=Domain,DC=com”
$Group = “CN=test-AK,OU=Groups,OU=IT,DC=Domain,DC=com”
#### AD Searcher. We will use it a several times
$ADRoot = [ADSI]“”
$Searcher = New-Object System.Directoryservices.DirectorySearcher($ADRoot)
$Searcher.SearchRoot = $ADRoot
$Searcher.SearchScope = “subtree”

#### Check if ManagedByName exists and get NT Authority name from it
$Filter = “(&(objectCategory=*)(distinguishedName=$ManagedByName)”
$Searcher.Filter = $Filter
$ADObjects = $Searcher.FindAll()
if ($ADObjects.Count -eq 0)
{
      Write-Host ($ManagedByName + ” has not been found”)
      return
}
$ManagedByObject = $ADObjects[0].GetDirectoryEntry()

#### Convert DN to Domain/username
if ($ManagedByName -match “(dc)+\s?(=).*”)
      {$DomainDN = $matches[0]}
else
{
      Write-Host “Error occurred while resolving the domain name”
      return
}
$Filter = “(&(objectCategory=*)(distinguishedName=$DomainDN))”
$Searcher.Filter = $Filter
$DomainObjects = $Searcher.FindAll()
if ($DomainObjects.Count -eq 0)
{
      Write-Host ($DomainDN + ” has not been found”)
      return
}
$DomainObject = $DomainObjects[0].GetDirectoryEntry()
$DomainName = ($DomainObject.Properties.Name[0]).ToUpper()

#### Parameters for new ACE
$ManagedByAccountObject = new-object System.Security.Principal.NTAccount($DomainName, $ManagedByObject.SAMAccountName)

$WritePropertiesObject = [System.DirectoryServices.ActiveDirectoryRights]::”WriteProperty”

$AllowObject = [System.Security.AccessControl.AccessControlType]::”Allow”

$WriteMembersGUID = [GUID]‘BF9679C0-0DE6-11D0-A285-00AA003049E2′

#### Group object
$Filter = “(&(objectCategory=*)(distinguishedName=$Group))”
$Searcher.Filter = $Filter
$ADObjects = $Searcher.FindAll()
if ($ADObjects.Count -eq 0)
{
Write-Host ($Group + ” has not been found”)
Return
}

$ADEntry = $ADObjects[0].GetDirectoryEntry()
$LDAPLine = “LDAP://” + $Group
$GroupObject = [ADSI]$LDAPLine
$GroupObjectSecurity = $GroupObject.PSBase.get_ObjectSecurity()
$GroupAccessRules = $GroupObjectSecurity.GetAccessRules($True,$True,[System.Security.Principal.NTAccount])

$NewAccessRule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($ManagedByAccountObject,$WritePropertiesObject,$AllowObject,$WriteMembersGUID)

$GroupObjectSecurity.AddAccessRule($NewAccessRule)
$GroupObject.Put(“managedBy”,$ManagedByName)
$GroupObject.PSBase.CommitChanges()

As easy as that.