A lot of Outlook issues are caused by various add-ins. So, disabling all add-ins is a useful step and should be the first step for Outlook troubleshooting.
Please note every add-in will be a subkey under the following subkeys.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins
HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins
HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Client\Extensions
HKEY_CURRENT_USER\Software\Microsoft\Exchange\Client\Extensions
So, to disable all add-ins thoroughly, we can follow the steps below.
1. Click start -> Run… -> Type "regedit" (without quotation mark) and Click OK
2. Locate the following subkey
3. Backup and Delete all subkeys under above subkey
4. Repeat step 1-3 for the remain 3 subkeys
Now, all add-ins are disabled. If the issue disappears, it means the root cause is a conflict between Outlook and some add-in. We can restore the registry back and delete them one by one to find out which one cause the issue.
When Internet Explorer 7 includes an add-on, Internet Explorer may exit immediately. This problem may occur if an add-on conflicts with Internet Explorer.
To resolve this issue, start Internet Explorer with add-ons disabled. To do this, click Start, click Programs, point to Accessories , point to System Tools, and then click Internet Explorer (No Add-ons).
If you start Internet Explorer with add-ons disabled, you may find that this resolves the issue. Then, you can locate and disable the add-on that conflicts with Internet Explorer. To do this, follow these steps:
1. Start Internet Explorer.
2. On the Tools menu, point to Manage Add-ons, and then click Enable or Disable Add-ons.
3. In the Manage Add-ons dialog box, click an add-on.
4. Under Settings, click Enable, and then click OK.
5. Restart Internet Explorer.
If the problem occurs, the add-on that you recently enabled conflicts with Internet Explorer.
6. Repeat steps 1 through 5 until you locate the add-on that conflicts with Internet Explorer.
The secure channel is used to validate the member servers or workstations membership in the domain, based upon its hashed password. This discrete communication channel helps provide a more secure communication path between the domain controller and the member servers or workstations. It can also be used to change the accounts password, and to retrieve domain-specific information, handling NTLM authentication pass-through to the domain controller, or from DC to DC for the same.
When you join a computer to a domain, a computer account is created, and a password is shared between the computer and the domain. By default, this password is changed every 30 days. The secure channel's password is stored together with the computer account on the domain controllers. Upon starting, Netlogon attempts to discover a DC for the domain in which its machine account exists. After locating the appropriate DC, the machine account password from the workstation is authenticated against the password on the DC. After the machine account is verified, the workstation establishes a secure channel with that DC. If it is a DC, when you start a PDC, Netlogon builds a list of all the BDCs in the domain, and a list of trusted domains. At this time, Netlogon attempts to set up a secure channel with a DC from each trusted domain, and if this attempt does not succeed, Netlogon does not make another attempt until a secure channel with that domain is explicitly needed. The BDC's behavior is similar. While Netlogon on a BDC does not enumerate other BDCs, it does contact the DC and sets up secure channels with trusted domains as needed.
Therefore, the Netlogon service on a workstation sets up a secure channel to a DC in its primary domain. The Netlogon service on a BDC sets up a secure channel to the PDC in its domain. The Netlogon service on a PDC sets up a secure channel to a DC in each of it trusted domains.
If there are problems with system time, DNS configuration or other settings, secure channel’s password between domain members and DCs may not synchronize with each other. AD replication issue, other electronic problems may cause secure channel broken to member servers. To DCs, the secure may broken due to communication issues.
When secure channel is broken, it may cause a lot of problems to Active Directory. Here we summarize some symptoms which indicate secure channel is broken. If you see the behavior, you can first check the secure channel before performing any further troubleshooting.
1. Replication error
When you use the Active Directory Sites and Services snap-in to manually replicate data between domain controllers, you may receive one of the following error messages:
The Target Principal Name is incorrect
-or-
Access is denied
You may get Netlogon event ID 3210, 5722 or NTDS KCC event 1925. For example, the following event ID messages may be logged in the system log:
Event Source: NetlogonEvent Category: None Event ID: 3210User: N/A Event Description: Failed to authenticate with \\DOMAINDC, a Windows NT domain controller for domain DOMAIN.
-and-
Event Source: NetlogonEvent ID: 5722Event Category: None User: N/A Event Description:The session setup from the computer 1 failed to authenticate. The name of the account referenced in the security database is 2. The following error occurred: n3
When you try to replicate changes between replica partners, you may receive the following error message:
The following error occurred during the attempt to synchronize the domain controllers. The naming context is in the process of being removed or is not replicated from the specified server.
2. Logon error
The client may be unable to log on to the domain. You may receive the following error message:
“Windows cannot connect to the domain either because the domain controller is down or otherwise unavailable or because your computer account was not found.”
Or
"The system could not log you on. Make sure your username and domain are correct."
3. Accessing resource
When you attempt to access shares on a server, you may get error:
"System error 1396 - Logon Failure: The target account name is incorrect."
4. Running nltest
nltest /sc_query: <domain_name>
-- Access is denied.
If you encounter the above behavior or error messages, suggest first reset secure channel. On the computer that are experiencing this issue, disable the Kerberos Key Distribution Center service (KDC) and then restart the computer. After the computer restarts, use the Netdom utility to reset the secure channels between the computer and the PDC Emulator operations master role holder. To do so, run the following command from the computer other than the PDC Emulator operations master role holder:
netdom resetpwd /server:server_name /userd:domain_name\administrator /passwordd:administrator_password
Where server_name is the name of the server that is the PDC Emulator operations master role holder.
Note: This method only works for DC. If it’s member server, we have to disjoin and rejoin domain.
For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
260575 How to Use Netdom.exe to Reset Machine Account Passwords
(http://support.microsoft.com/kb/260575/EN-US/)
If the problem is not resolved or secure channel keeps being broken, you may need to find the root cause by performing further diagnosing or troubleshooting.
You may experience the issue about no SeIncreaseQuotaPrivilege privilege under “Local Service” account after joining Vista to Windows 2000 domain. This could cause several services (Telnet, Firewall etc) not being able to start. The typical symptom is described as follows:
When joining Vista client to Windows 2000 domain, after Vista client receive group policy and reboot. it will have some problem to manage the firewall settings.
1. Windows Firewall service (mpssvc) cannot be started with error message "1279, a privilege that the service requires to function properly does not exist in the service account configuration"
2. Cannot open "Windows Firewall with Advance configuration Security", the MMC snap-in will return error 0x6D9
It is because SeIncreaseQuotaPrivilege for “Local Service” account is missing. In Windows Vista, SeIncreaseQuotaPrivilege privilege is required to start Firewall service and the account to start Windows Firewall service is "Local Service", (this is different to the Local System). In Windows 2000 Domain environment, the default confgiruation for "Increase Quota" is only assigned to Administrators. Thus after Vista get the domain policy, the Local service's SeIncreaseQuotaPrivilege will be revoked.
The solution is to give SeIncreaseQuotaPrivilege to Local Service.
To do that, open group policy editor and locate Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment
On Windows 2000 Group policy Editor, Find "Increase Quota" and add "Local Service" to the list
Other information
Windows 2000 AD, the default confgiruation for "Increase Quota" is assigned to Administrators. From Windows 2003, it will change the policy name to "Adjust Memory quotas for a process” and be given to Administrators. Local Service, Network Services and IWAM_[machinename] by default.
Two Microsoft Knowledge Base articles have been recently published to clarify and update Microsoft Support Policy on Exchange Tools. Microsoft Customer Support Services (CSS) supports the Microsoft Exchange Server 2003 tools that you can download from the Microsoft Download Center Web site. Support includes installation and usage of the tools, as well as errors encountered while using the tools.
CSS supports the Exchange Server 2003 tools that you can download from the Download Center
http://support.microsoft.com/?id=928583
The Exchange Server Quota Message Service tool is supported by Customer Support Services
http://support.microsoft.com/?id=928582
In Windows 2000 and Windows Server 2003, Unicast NLB nodes cannot communicate over the NLB-enabled network adaptor. In order to enable the communication between the Unicast NLB nodes, we have to install additional network cards on the computers so that they communicate using the additional network cards.
In Windows Server 2003, Microsoft has implemented the feature for Unicast NLB nodes communicating over the NLB-enabled adapters. In order to enable this feature, the registry value UnicastInterHostCommSupport needs to be added.
Please refer to this Knowledge Base article for more information.
898867 Unicast NLB nodes cannot communicate over an NLB-enabled network adaptor in Windows Server 2003
http://support.microsoft.com/default.aspx?scid=kb;EN-US;898867
A typical problem we usually meet is:
We have java applets installed on client computers. When “Automatically Detect Settings” option is checked in IE, these applets won’t work. They will either fail to start or can’t communicate.
Actually this is not an ISA issue. Java applets run in Java VM, thus, “sandbox”. Inside the sandbox, everything is independent from IE, including Internet access.
In implementation of Sun’s JRE, the VM will adopt IE’s proxy settings. So if “automatically detect settings” is selected, the VM has to detect the proxy server itself, through the WPAD mechanism.
Per our test result, current JRE versions will behave abnormally when “automatically detect settings” and can’t fetch the correct proxy address.
If you or your customer met this issue, please contact the Java applet vendor or Sun Microsystems directly about the new version.
RMS Server SP2 is released on Dec and available for download.
http://www.microsoft.com/downloads/details.aspx?FamilyID=5794538f-e572-4542-a5bd-901b2720f068&DisplayLang=en
New features in SP2:
l Native support for SQL Server 2005
l Support for SharePoint Server 2007
l Security and flexibility enhancements
For more details, please refer to:
http://technet2.microsoft.com/WindowsServer/f/?en/Library/db48fba3-675f-4598-bdd5-6ee4c7c0e70f1033.mspx
Microsoft Windows 2000 Server, and especially Advanced Server with its clustering support, provides an excellent environment in which to build a truly fault-tolerant system. Of course, avoiding the faults in the first place is even better than handling them once they've happened, but the realistic system administrator knows that a problem will occur sooner or later and he or she can plan for it. Chapter 33 (from “Microsoft Windows 2000 Server Administrator's Companion”, published by Microsoft Press) covered disaster planning in depth, so you should refer to that chapter for information on how to prepare for major problems and how to build a full disaster recovery plan to quickly resolve them.
A typical cluster issue includes one or more of the following symptoms:
1. Quorum disk is not accessible
2. Cluster service cannot start
3. Network access loss
4. Cluster setup problem
5. Cluster resource failure
6. Cannot fail over cluster resource
Please refer to the article below for details:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/plan/planning.mspx#EKD
Key Management Service (KMS) enables organizations to perform local activations for computers in a managed environment without the need to connect to Microsoft. A KMS key is used to enable KMS on a computer controlled by the system administrator in an organization. KMS activation is targeted at managed environments where more than 25 computers are connected to the organizational network. Computers running Windows Vista activate by connecting to a central Windows Vista computer running KMS.
Top Questions
1. How to install and configure a KMS activation?
Answer: Please refer to the technical document: http://www.microsoft.com/technet/windowsvista/plan/volact1.mspx#StepsforImplementingConfigDeployingKMS
2. What is the anticipated network traffic for KMS activation?
Answers: Approximately 250 bytes are sent in each direction for a complete client-KMS exchange, plus TCP session overhead. The only additional network traffic is for auto-discovery, which usually occurs only once per client computer, as long as the same KMS continues to be available for subsequent renewals.
3. Could the KMS server be installed on a Windows Server 2003 server?
Answer: Yes, Windows Server 2003 KMS service for Volume Activation 2.0 is currently under development with expected availability in 2007.
4. Are there any high availability options for KMS (such as clustering or network load balancing)?
Answer: A form of load balancing is built in for DNS autodiscovery. Computers query the list of KMS machines returned by DNS and choose one at random. If this location becomes unavailable, they then choose another. If DNS autodiscovery is not used, robin-robin load balancing can be implemented using a CNAME record with multiple A / AAAA records – or even using a Cisco Director or equivalent.
Reference
=======
Volume Activation information for Windows Vista http://support.microsoft.com/kb/929712/en-us
KMS Activation FAQ http://www.microsoft.com/technet/windowsvista/plan/faq.mspx#EEBAC
A while back we got involved in a weird issue where a network user encountered network share access problems. The symptom or the error message might be different in some scenarios:
1. Domain controller’s share folders cannot be accessed by the NETBIOS name, but the folders can be accessed by the IP address several times.
2. The access to the \\servername\ could be succeeded, but the error message will be shown if to access the shared folder under it, such as \\servername\netlogon or \\servernam\sysvol. 3. \\machinename\folder is not accessible, the message says that you might not have permission to use this network resource. Contact the Administrator of this server to find out if you have access permission. Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied. See the below screen capture. When the problem happens, we always get the following error message: "LSASRV EVENT ID:32772 The interdomain trust account for the domain <Domain> could not be created." This "LSASRV EVENT ID: 32772 message would be a good hint to help us narrow down the issue and figure out the root cause. At this moment, when opening the “Active Directory Domains and Trusts”, we can see there is an invalid trust existing and the trust was created to setup trust with the DC itself, which is abnormal behavior. Unfortunately, when trying to delete the trust object from trust list, there will be error showing as “An internal error occurred” or “the directory service is busy”. We have to go to Adsiedit.msc console to delete the trust object directly: CN=<Trusted/Trusting Domain NETBIOS name>,CN=system,DC=Domainname,DC=com After deleting the invalid trust objects and restarting the domain controllers, the Drive mapping and the share folder can be accessed by the machine NETBIOS name turn to be successful. NOTE: After removing the trust object, it is recommended to restart all domain controllers within the domain. If not , the trust list is not consistent throughout the domain controllers. Some domain controllers UI reported the trusts were there but “nltest /domain_trusts” returned the correct result. So the restart of all the domain controllers after the removal operation will purge the netlogon trust list cache. It is also recommended to restart the problematic clients to make the changes effective.
3. \\machinename\folder is not accessible, the message says that you might not have permission to use this network resource. Contact the Administrator of this server to find out if you have access permission. Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied. See the below screen capture.
When the problem happens, we always get the following error message:
"LSASRV EVENT ID:32772 The interdomain trust account for the domain <Domain> could not be created."
This "LSASRV EVENT ID: 32772 message would be a good hint to help us narrow down the issue and figure out the root cause. At this moment, when opening the “Active Directory Domains and Trusts”, we can see there is an invalid trust existing and the trust was created to setup trust with the DC itself, which is abnormal behavior.
Unfortunately, when trying to delete the trust object from trust list, there will be error showing as “An internal error occurred” or “the directory service is busy”. We have to go to Adsiedit.msc console to delete the trust object directly:
CN=<Trusted/Trusting Domain NETBIOS name>,CN=system,DC=Domainname,DC=com
After deleting the invalid trust objects and restarting the domain controllers, the Drive mapping and the share folder can be accessed by the machine NETBIOS name turn to be successful.
NOTE: After removing the trust object, it is recommended to restart all domain controllers within the domain. If not , the trust list is not consistent throughout the domain controllers. Some domain controllers UI reported the trusts were there but “nltest /domain_trusts” returned the correct result. So the restart of all the domain controllers after the removal operation will purge the netlogon trust list cache. It is also recommended to restart the problematic clients to make the changes effective.
The final release of the new Firewall Client for ISA Server is now available for download at:
http://www.microsoft.com/downloads/details.aspx?FamilyId=05C2C932-B15A-4990-B525-66380743DA89&displaylang=en.
The new version can be installed on computers running Windows 2000, Windows NT 4.0, Windows Server 2003, Windows XP, and Windows Vista. It also includes software updates that improve the security and stability of Firewall Client software.
For more information, please refer to the Knowledge Base article:
929556 How to obtain the version of Firewall Client for ISA Server (December 2006) that includes Windows Vista support
We’d like to bring you attention to three recently released Knowledge Base articles which address some common issues SMS support has seen as of late.
The first involves the Patchinstall.exe program and how it may be successfully invoked. This article should help you spot a potential incorrect call of Patchinstall.exe which results in the patch install failure. This issue commonly manifests in Operating System Deployments where an action to install patches outside of the SMS clients ITMU Scan and Patch process is undertaken:
KB 926732 When you run the SMS 2003 PatchInstall.exe program to install updates on client computers, those updates may not be installed
The second issue also involves Patch failures and is seen when the Automatic Updates service is not functional on the client. This service is an integral part of the process but may have been disabled leading to this problem:
KB 925640 Client computers are not updated with advertised packages, and exit code 1058 is generated, after you configure the Inventory Tool for Microsoft Updates (ITMU) in SMS 2003
Finally the last involves Database Growth after the upgrade to SP2 for those customers who are also using System Center Reporting Manager:
KB 926731 The SMS database may unexpectedly increase in size after you install SMS 2003 Service Pack 2
We hope raised awareness of these common problems will speed you back to a healthy and functional site - and save you a support call!
With improvements in Exchange Server 2007, some of the common issues hit by users when using the Out of Office Assistant are addressed:
l Users sometimes forget to turn the Out of Office assistant on and off, because it cannot be scheduled in advance. Exchange Server 2007 provides end users the ability to schedule OOF times in the future.
l Users would like to send more detailed Out of Office information to their co-workers, but send more generic information to external senders. Exchange Server 2007 allows end users to set separate internal and external OOF messages.
l Some users want to send their Out of Office messages only to a limited set of external contacts, but not anyone who might email them – for privacy reasons. In Exchange Server 2007, users can choose to send their external OOF message only to their external contacts.
Exchange Server 2007 provides both end-users and administrators with great flexibility in configuring OOF to well meet various requirements. The article at Microsoft Exchange Tam Blog Web site contains details on this topic http://msexchangeteam.com/archive/2006/10/06/429115.aspx