Troubleshooting 1030/1058 event ID error - one of the many cases

Userenv event ID 1030/1058 pair are very common errors that could be caused by various things. Common causes would be secure channel broken, domain account corrupt, client side group policy extension issue, etc. A brutal but simple solution will be quit/rejoin domain provided you are VERY sure your network and DCs are working properly. If DC or client side extension are in question, you would most likely want to enable userenv log as per KB 221833.The example below is certainly not the most difficult one but shows typical troubleshooting tools when the network is in doubt.

1030/1058 pair in application log, GP not applied

• Event Type: Error
• Event Source: Userenv
• Event Category: None
• Event ID: 1058
• Date: 10/31/2006Time: 10:09:28 AM
• User: NT AUTHORITY\SYSTEM
• Computer: server1
• Description:Windows cannot access the file gpt.ini for GPO cn={B8F49320-CB4A-4660-9BF5-806926B63906},cn=policies,cn=system,DC=samle,,DC=com. The file must be present at the location <\\sample.com\SysVol\sample.com\Policies\{B8F49320-CB4A-4660-9BF5-806926B63906}\gpt.ini>. (Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied. ). Group Policy processing aborted.

- nltest /sc_query:shortDomainName OK (to rule out security channel issue)

- netdiag /v: DC List Test failed. (The DC is down)Trust Relationship test failed

Note: if you open a cmd as local system, the domain membership test will be failed in netdiag - this is normal

The following 3 commands to test connectivity

• ping shortDomainName OK
• portqry test against all required ports OK
• ping -l oversizePacket -f OK

Further troubleshooting:

• Suspected NetBIOS was not enabled, went into TCP/IP setting, but it's ticked
• Nslookup: Short domain name not resolved.
  Action: change suffix then flush DNS cache
  Result: short domain name resolved, but "DC list test" still failed
• Found another symptom: Couldn't log into this box via TS, error "RPC server is not available". Check the RPC service and RPC Locator service, found the later was not running while this was a W2k member server.
  Action: start RPC Locator service
  Result: not difference
• Checked application log again, 1030/1058 started on Oct 26. Checked System Log to see if there was anything happened at that day, it reported "tcp/ip NetBIOS helper" service terminated unexpectedly". This service is NetBIOS over TCP/IP itself.
  Action: started it.
  Result: netdiag came back clean

Actually I should have checked services status before even begun troubleshooting. Those set to "automatic" should be running - this is a quick way to find problems sometimes. But anyways, this can serve as an example of using different tools when network is in doubt.

How To User Mailbox Management Policy

1. Define a policy in "Recipient Policies" container. Make sure you have correct filters and actions defined.
2. Apply the policy immediately/manually or wait for RUS kicks in overnight
3. Define a Mailbox Management schedule on *ALL* involved servers
4. At this point, you can wait for the scheduled Mailbox Management process to launch or manually run it by selecting ?Start Mailbox Manager?

Note: Mailbox Management policy is not the same as System Policy that applies to either mailbox stores or servers. Mailbox Management policy is defined in Receipient Policy container while System Policy is defined under server object.

DNSBL - email block list

A DNS-based Blackhole List (DNSBL, also known as Real-time Blackhole List or RBL), is a means by which an Internet site may publish a list of IP addresses, in a format which can be easily queried by computer programs on the Internet. As the name suggests, the technology is built on top of the Internet DNS or Domain Name System. DNSBLs are chiefly used to publish lists of addresses linked to spamming. Most mail transport agent (mail server) software can be configured to reject or flag messages which have been sent from a site listed on one or more such lists.

How Block List Providers Match Offending IP Addresses

After you set up your connection filter, when an e-mail message is sent to your organization, Exchange contacts the block list provider. The provider checks for the existence of an A (host) record in its DNS. Exchange queries for this information in a specific format. For example, if the connecting address is 192.168.5.1, and the block list provider's organization is contoso.org, then Exchange queries for the existence of the following record:

;. IN A 127. 0.0.x

which, in this case, is:

1.5.168.192..RBLprovider.org

If this IP address is found on the provider's list, the provider returns a 127.0.0.x status code that indicates an offending IP address and the type of offense. All block list providers return a response code of 127.0.0.x, where x indicates the type of offense. This number varies, depending on the block list provider.

Although few people object to the principle that mail-receiving sites should be able to reject undesired mail systematically, many have voiced objections to specific DNSBLs for the following reason:

For Joe Blow to refuse emails is legal (though it's bad policy, akin to "shooting the messenger"). But if Joe and ten million friends all gang up to make a blacklist, they are exercising illegal monopoly power.

Tips:

• After a filter is defined, it will not take effect until it's applied to a smtp virtual server
• Recipient filtering rules apply only to anonymous connections. Authenticated users and Exchange servers by pass these validations
• Likewise, connection filters apply only to external connections. Connections made by Exchange servers within the same organization will not be affected.