Corrective Actions:
Check for lack of rights and other settings by going through the following

• The Windows user selected during the gateway install cannot have deny rights of "send as and receive as" on the Exchange mail store inherited from the groups he is a member of
• The user that was selected during the installation to run the gateway should not be changed. If this has been done, please change back to the original user or reinstall the Exchange Gateway
• To check for "deny' rights, enable the hidden security tab at the top of the Exchange organization to view rights from the top container. http://support.microsoft.com/?id=259221
• Use ADSIedit and look for deny on the "send as and receive as" rights from the mail store up on user and the groups he is a member of
• The windows user specified during the install should be a member of the following and not be one of the predefined built in Windows users accounts. For example, Administrator. Administrator account (built in account) will have explicit and inherited deny rights that may interfere with the gateway starting. Rather then using a built in account create a new account and give the user membership to the following groups:
  
  Domain admins, Schema admins, Enterprise admins, Exchange Domain Servers (as per the Gateway read-me section 4.1)
• Check each of these groups rights for "send as and receive as" on the mail store to ensure they are set to allow. Remove all deny rights to the"send as and receive as" attributes
• The "send as and receive as" rights are further complicated by the addition of the Microsoft servers DST patch and is noted in the Microsoft KB 926666 http://support.microsoft.com/kb/926666
• The "send as and receive as" rights can be reset for the built in accounts as per the above KB and that is the reason, it is recommended not to use a built in account to run the gateway
• Ensure that the user starting the gateway is allowed to start a service. Click Start | Administrative tools | Domain Controller Security Policy | Local Policy | Log on as a service |. Right Click and click Properties and add the user starting the gateway
• Check that the path in the registry setting is correct and modify if needed HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Groupwise Gateways\Exchange\domainname\gatewayname\Parameters Domain Value. This has been noted to be pointing to a Child domain and or Parent when it needs to be pointing to the Domain
  
  * The error above in the log file shows the full path in AD to the connector and is sometimes what is seen if this registry setting is not correct
  * This error is also see when rights to the mail store include a deny as the gateway is not able to find or access the mail store
• Make sure to use the latest Exchange Gateway code available from Novell's software download site.
  

Being able to run the Gateway as an application while not as a service is a possible work around

• Try to launch the Gateway as an application rather than as a service by going to the GroupWise Domain directory\wpgate\exchange\exgate.exe. Launching as an application can help if the logging is set to verbose as it may show errors not seen in the logs while launching as a service
• Enable verbose logging in the gateway under ConsoleOne and check gateway logs in GroupWise Domain directory\wpgate\exchange \000.prc for errors that may help to trouble shoot this issue
• Checking the Windows Server event logs can assist in finding why the Gateway in unable to start
• Make sure to use the latest Exchange Gateway install code from Novell. Latest code can be received by opening a Service Request with Novell Technical Services. (At the time of writing this TID, Novell has a build being tested but not released dated 9-25-07). If no further support is needed at the time of the call the SR will be credited/refunded

Notes: