SMTP Virtual Server vs. SMTP Connector

SMTP Virtual Server vs. SMTP Connector
1. SMTP virtual server is the protocol stack that actually does the work - sending/receiving SMTP emails. SMTP virtual server alone gives you ability to send/receive Internet emails.
2. SMTP Connector is built on the top of virtual server and provides you more control - such as dispatching emails to different domains to different routes, applying different restrictions, etc.
3. SMTP virtual server only sends/receives emails to/from the IP address it is bound.
4. As for DNS, either specify external DNS servers on SMTP virtual servers or specify forwarder on DNS server that Exchange server uses.
5. The benefits of SMTP Connector are 1) ease of administration; 2) to simplify troubleshooting when issue surfaces.
6. You can either have your SMTP connector delivery the emails directly (given that the connector is able to resolve external domain names - using one of 2 settings in item 4 )
- or -
You can have your SMTP connector forward all emails to a smart host. Although you can specify a smart host on an virtual server, it’s better to set it on the connector. The smart host setting on the connector overrides any smart hosts on the virtual server.

VBscripting tips

1. To make sure you fetch the output only after the command finishes, add the following between shell.exec and stdout.all
   Do While oExec.Status = 0
   WScript.Sleep 100
   Loop
2. To pipe output from one process to another
   Dim oUserDN

• set oShell = createobject("wscript.shell")
  mystr = "dsquery user -samid %username% -o dn dsget user -memberof"
  set oUserDN = oShell.exec("%ComSpec% /c """ & mystr & """")
  Wscript.Echo oUserDN.StdOut.readall

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.