If you are calling the method to perform the extended property check but the results are still coming back false when cookies are indeed enabled - this can happen for a number of reasons:

1. When testing whether the user's browser supports permanent cookies BrowserHawk uses a cookie expiration date of 2 days from the time of the cookie check. If your web server's clock is behind by more than two days the user's browser will not accept the cookie because it thinks it has already expired. The same situation occurs if the end user's system clock is ahead by 2 days. And finally, this situation can occur due to a combination - such as your server being behind 1 day and an end user being ahead by one day, etc. Note that all times are adjusted for GMT so time zone differences have no affect - the affect is only caused by a bad (too far behind or too far ahead) clock setting.

   If you are encountering this issue, make sure that your web server's system clock is set correctly. If your server is a Member Server of a Primary Domain Controller (PDC), and you are using Network Time Protocol, be sure to set the clock correctly on the PDC. If you only experience this issue with a given end user, have them verify that their system clock is set correctly.

   Note: Starting in BrowserHawk 8.0 there is an option for raising or lowering this 2 day threshold to account for possible clock errors should you prefer to set your own default expiration period. See the CookieDuration property in the documentation for more information.

2. You or your site visitors may be behind a firewall or proxy servers configured to filter out cookies. In some cases the configuration may allow session level cookies but not permanent cookies. In this situation BrowserHawk will properly return information to indicate that session cookies are enabled but permanent cookies are disabled. Even though the user has their browser set to enable cookies, they are indeed not reaching the browser. Therefore, BrowserHawk will properly indicate this by setting the cookie status to disabled as appropriate. This behavior is by design. If you or an end user of yours is experiencing this issue, you should closely examine the firewall and/or proxy servers that sit between the browser and the server and ask for your administrator's assistance in tracking down the issue. If you are only concerned about session level cookies you can use the CookieCheckType property to tell BrowserHawk to set CookiesEnabled to True for users of IE 5 and later as long as their session cookies are on.
3. If using the ActiveX version of BrowserHawk: For IE browsers version 5 and up, BH only sets CookiesEnabled to True if both session and permanent cookies are enabled in the browser. You can change this default behavior by using the CookieCheckType property.
4. There have been cases with IE 6 where a user may have their browser configured to accept cookies, but they are still being rejected by the browser, and vice-versa. In this event, BrowserHawk *always* provides the true answer as to whether or not the browser is accepting cookies, despite how the browser may be configured. You can prove that the BH result is correct by creating a test page that sets a cookie, and another test page that displays the result of the cookie. That way you can confirm that the answer provided by BH is indeed accurate.
5. If you have load balanced servers, be sure you are setting the CookieDomain property properly. Typically this should be set to: .yourdomain.com (note: the pre-appended dot before the domain name is intentional). See the documentation for details.