Page 8 of 8 FirstFirst ... 345678
Results 141 to 153 of 153
  1. #141  
    Quote Originally Posted by GoodGuy
    You got it in the next version. That, by the way, is not a bug.
    WOW THANKS GOODGUY! I WILL LOOK FOR IT WHEN THEY RELEASE BB CONNECT.


    Quote Originally Posted by GoodGuy
    Funny, how when you used to work here, it wasn't a problem.
    HaHa...
  2. #142  
    Congrats guys, just like several of the same characters did here, http://discuss.treocentral.com/showthread.php?t=88167, we've managed to turn an interesting technical discussion/debate into a bunch of juvenile, personal, finger-pointing that renders the thread all but useless to the rest of us.
  3. #143  
    In Will Direct Push Make Windows Mobile?, Email Battles reports: "In the war of attrition for mobile-OS dominance, Microsoft's Direct Push technology in Exchange Server 2003 SP2 may finally give Redmond the edge.

    "Competitors who crow that it's not secure enough leave out one key word: "Yet." Microsoft's betting that cash-strapped network managers will be willing to buy its one-stop solution and wait."

    The article refers to comments in this thread. My takeaway: 1) Convenience sells more stuff than the compelling combination of security and the direct push method chosen. 2) Ultimately Microsoft will win, but who knows how long it will take?
  4. Cartman's Avatar
    Posts
    700 Posts
    Global Posts
    879 Global Posts
    #144  
    Woohoo, I've bee quoted!

    ...as being "twistedly optimistic"



    LOL
  5. Cartman's Avatar
    Posts
    700 Posts
    Global Posts
    879 Global Posts
    #145  
    The new features of SP2 for Exchange will not be limited to WM5 devices with MSFP.

    Ed Hott, Director of Business Develpment for Microsoft Exchange with primary responsibility for the Exchange Licensing Protocal says:

    We license the ActiveSync protocol so that other mobile devices can interact with Exchange in the same rich and efficient way that Windows Mobile does. Our goal is to enable customers to use their favorite mobile device(s) with Exchange - even if that device isn't a Windows Mobile device. With that in mind, ActiveSync licensees have access to the exact same functionality through the protocol that we provide to Windows Mobile. Nothing in the protocol is reserved for Microsoft-only use.
    He goes on to say:

    My comments are in no way intended to imply that we aren't 100% behind Windows Mobile nor believe that Windows Mobile doesn't have a bright future. We are and it does. But we also recognize that customer preferences vary widely when it comes to mobile devices, and having lots of choices is a good thing for Exchange customers.
    And end with:

    And I believe DataViz's Roadsync Technology Preview for Exchange Service Pack 2 is the first publicly announced offering from an ActiveSync licensee with support for SP2.
    Read the whole thing here:

    On ActiveSync and our partners
  6. Cartman's Avatar
    Posts
    700 Posts
    Global Posts
    879 Global Posts
    #146  
    New Mobility Features in Exchange Server 2003 SP2
    Published: November 2, 2005

    This article discusses some of the new features in Exchange Server 2003 SP2.

    sumed up:

    Exchange ActiveSync
    Benefits of Exchange ActiveSync are:

    • Exchange ActiveSync is built into Exchange Server so that you do not need additional software or servers.

    • Exchange ActiveSync gives users a consistent Microsoft Office Outlook® experience across the users' environment.

    • Exchange ActiveSync does not require any desktop software or connection software.

    • Exchange ActiveSync does not require special data plans or subscriptions. A user can buy as much data as he or she needs through a standard data plan and can use his or her mobile devices globally.


    Exchange Direct Push Technology
    • A standard data plan is the only subscription you need to have to synchronize with Exchange Server.

    • It works globally.

    • No need to deploy additional infrastructure in your Exchange Server environment.

    • No need for SMS notification or any other “out-of-band” schemes.

    • No special configuration on the mobile device.


    Direct push is enabled by default. The immediate effect of direct push is that you will see an increased number of open connections that the server must handle. This increase in connections puts more pressure on the memory, but not necessarily on the CPU. With the memory improvements in Windows Server™ 2003 SP1, it is recommended that you run Exchange Server 2003 SP2 on this version of the Windows® operating system.

    Direct push is designed to minimize the effect to e-mail traffic. For example, the synchronization operations that are performed in direct push are targeted at only those folders that contain changes, so you’re never issuing a lot of empty synchronizations as you would with a scheduled or manual synchronization. There are other optimizations that are performed both by the server and the mobile device.

    Remote Wipe
    • View a list of all mobile devices that are being used by any enterprise user.

    • Send or cancel remote wipe commands to mobile devices.

    • View the status of pending remote wipe requests for each mobile device.

    • View a transaction log that indicates which administrators have issued remote wipe commands, in addition to the mobile devices those commands pertain to.

    • Delete an old or unused partnership between devices and users.


    The Microsoft Exchange ActiveSync Mobile Administration Web tool will be available from the Exchange Server 2003 Tools download center in late 2005.

    Device Password Policies

    • Minimum password length (characters) This option specifies the length of the password for the device. The default is four (which is also the minimum length). You can specify up to 18 characters.

    • Require both numbers and letters This option determines password strength. You can enforce usage of a character and/or symbol in the password.

    • Inactivity time (minutes) This option determines how long the device needs be inactive before the user is prompted for the password.

    • Wipe device after failed (attempts) This option lets you specify whether you want the device memory wiped after multiple failed logon attempts.

    • Refresh settings on the device (hours) This option forces the mobile device to verify and re-download the policies at set intervals.

    • Allow access to devices that do not fully support password settings This option permits you to specify whether devices that do not fully support the device security settings are able to synchronize with the Exchange Server.

    • Exceptions You can specify users who are exempt from the configured settings by adding the users to the Device Security Exceptions List.
  7. Cartman's Avatar
    Posts
    700 Posts
    Global Posts
    879 Global Posts
    #148  
    White Paper on Mobile Messaging with Microsoft Exchange Server 2003 SP2 and Windows Mobile 5.0


    "This white paper examines how Microsoft responds to the evolving mobility needs of your business. Microsoft Exchange Server 2003 communication and collaboration server with Service Pack 2 (SP2), and Windows Mobile 5.0 with the Messaging and Security Feature Pack (MSFP) deliver an integrated, scalable, security-enhanced and cost-effective enterprise mobile messaging solution."



    Microsoft has just released a white paper detailing the benefits of a joint Exchange Server 2003 SP2 and Windows Mobile 5.0 solution with the focus on maximising mobility for businesses. Of course, this is also a solution that is dependent on the Messaging and Security Feature Pack (MSFP), which annoyingly, will only be made available through OEMs and operators from early Q1 2006, not directly through Microsoft.
  8. Cartman's Avatar
    Posts
    700 Posts
    Global Posts
    879 Global Posts
    #149  
    http://blogs.msdn.com/jasonlan/archi...03/499714.aspx

    So how Does Direct Push actually work and the FUD currently circulating....
    During our Exchange Unplugged Tour I've been explaining how the Direct Push technology works in Exchange 2003 Service Pack 2.

    The Exchange team wrote a great blog on this which few people seem to have seen - http://blogs.technet.com/exchange/ar...07/406035.aspx

    The Summary is that when we designed this technology we considered the following

    The deployment of AUTD must be turn-key for the administrative staff. Just install Exchange, check a checkbox or two, and you’re off and running.
    The deployment of AUTD must not require a business relationship between any of Microsoft, the enterprise deploying AUTD, or the mobile operator.
    The solution must not require a network operations center (NOC).
    Since, by and large, mobile devices are not internet-routable without a NOC and without having first contacted an internet-resident peer, the means by which AUTD works must be initiated by the device.
    Enterprise administrators will laugh at us if we ask them to open inbound ports on their networks other than 80 (HTTP) and 443 (HTTPS). Some of them laugh at us, anyway.
    There must be no notion of “dropped” notifications.
    The device side of the solution must not require any provisioning beyond what the user must already do in order to setup ActiveSync.
    Within this definition of the problem, we came up with the following solution:

    The device issues an HTTP request to Exchange, which asks Exchange to report any changes that occur in the mailbox of the requesting user within a specified time limit. The URL of this HTTP request is the same as that of other AirSync commands ("/Microsoft-Server-ActiveSync") with some differing query string parameters. The body of the HTTP request allows the client to specify those folders that Exchange should monitor for changes. Typically, these will be the Inbox, Calendar, Contacts, and Tasks folders.
    Upon receiving this request, Exchange will monitor the specified folders until either the time limit expires or a change (such as the arrival of a piece of email) occurs in one of those folders, whichever comes first. Exchange will then issue a response to this request that notes in which folders the changes occurred. Of course, this will be empty if the time limit elapsed before any changes occurred.
    Upon receiving an empty response, the device simply re-issues the request. This loop of issuing a request for change notifications, receiving an empty response, and re-issuing the request for change notifications is called "the heartbeat."
    Upon receiving a non-empty response, the device issues a synchronization request against each folder in the response. When those complete, it re-issues the request for change notifications.
    With this approch we remove the need for a relay or Network Operations Centre (NOC) avoiding the need to relay data and also add cost to the overall solution. We still however provide the exact same experience of other mobile email 'push' solutions.

    There seems to be lots of mis-conceptions out there that are being circulated by various parties about this architecture - I've outlined a few of them below.

    1) Scaleability - I've seen some of our competitors make false statements about the fact that our solution will massively impact the network and firewall and it won't scale. This is totally wrong - we have over 45,000 Windows Mobile Device users in Microsoft using this technology already – we support them from 2 Servers in Redmond with just 4 employees supporting the whole service. . Those Servers are dual pentium - 2GB RAM machines. We have a public document showing Microsoft IT’s own scaleability experience with our product http://download.microsoft.com/downlo...calability.doc

    2) Having an incoming firewall port is bad - Opening port 443 (SSL) is actually not such a big deal that some of our competitors make out. Port 443 is the same port used for Outlook Web Access and RPC/HTTPS - a large majority of customers already provide this service over the Internet or through a private APN/VPN. There will always be a small majority who won't want to do this - but it is a small majority.

    3) We don't use SMS (short message service) anymore!!! - The previous Always Up to Date solution (AUTD) used SMS as a trigger mechanism - we use IP in the Exchange 2003 SP2 solution - not SMS - a few people still seem to think we use SMS - we don't.
  9. #150  
    Quote Originally Posted by GoodGuy View Post
    Windows Mobile being FIPS 140-2 means nothing. MSFP is NOT FIPS 140-2 certified. Having the OS being certified is a the moot
    The WM5 platform is FIPS certified. I know Good is too but what does Good have over Microsoft as it relates to FIPS?

    Thx,
    Moose
  10. #151  
    Any response to the FIPS question? I am very interested to know what a Good device has over a WM device as it relates to FIPS. Because if Good is going to say "Good encrypts all PIM data at rest where WM5 doesn't therefore WM5 is not FIPS" this is misleading;

    You could then make the argument that Good is not FIPS because only PIM data at rest is encrypted but not other data including on SD cards.
    Last edited by MooseFruit; 09/29/2006 at 10:06 AM.
  11.    #152  
    Quote Originally Posted by MooseFruit View Post
    Any response to the FIPS question? I am very interested to know what a Good device has over a WM device as it relates to FIPS. Because if Good is going to say "Good encrypts all PIM data at rest where WM5 doesn't therefore WM5 is not FIPS" this is misleading;

    You could then make the argument that Good is not FIPS because only PIM data at rest is encrypted but not other data including on SD cards.

    Good data on the SD card is encrypted. They key to our FIPS certification is that our encryption is end to end AND all Good related data on the device, including any Good data on the SD card.
  12. #153  
    Thanks for the clarification.
Page 8 of 8 FirstFirst ... 345678

Posting Permissions