1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Maximum number of aliases

Discussion in 'Software' started by g.vangemerden, Aug 16, 2007.

  1. g.vangemerden

    g.vangemerden Bit Poster

    Hi there,

    My company wants me to setup some kind of servicedesk-registrationtool based on Exchange 2003. The idea is that a customer can email questions to us, which will be answered by one of the employees.

    The structure desired is as follows:

    and so on...​
    Now, all the questions in all the different categories from all the different companies needs to be answered by just 4 people. There is a schedule who will answer the questions at what time of the day.

    Since my co-workers have to answer questions from all of the folders, they don't like to monitor 60 folders or so (based on three categories for 20 companies). So they have decided all the emails should come in at the servicedesk-account. BUT... every folder (ie. category) needs its own emailaddress. So there shall be a 'categoryA-company1'-emailaddress and a 'categoryC-company5'-emailaddress and so on...

    The empolyee-on-duty will move the emails into the correct folder.

    All these emailadress should, in this scenario, be aliases of the

    .. hold on, here come the questions ;-) ...

    1. Is it correct that the best practice for this, is to make it public-folder-based in stead of a normal account?

    2. Is it possible to create that much aliases to just one
    mailbox/publicfolder (in this case the 'servicedesk'-box will get 60 aliases)

    3. How many aliases can an object (whether its a mailbox or a public folder) have anyway, considiring future growth...


    Certifications: See signature..
  2. Fergal1982

    Fergal1982 Petabyte Poster

    I wouldnt make it a public folder myself. Public folders are just one big pst file, and they are utter crap to be honest.

    At my old place all our servicedesk members had access to a single mailbox (user account with email address that wasnt used to log on). You just need to create a servicedesk group and grant it full mailbox rights to the mailbox in question. you can then add all the necessary members into the group to grant access. If you combine this with the group your servicedesk use for access rights, then it makes it easier to handle.

    As for smtp's against a single mailbox, a quick google indicates that its possibly 100 smtps. Theres an easy way to test it though. Just create a dummy account, and give it as many smtps as you can if it errors then theres your limit, if it doesnt, wait for replication to create the mailbox, double check its ok, then add more. repeat until you are satisfied with the number.

    EDIT: its worth pointing out that you can have as many incoming addresses as you like on an account but only one outgoing addresses. SO whilst they may email [email protected], replies from that particular mailbox will always come from [email protected], regardless of the incoming address.

    Also, even if the limit on smtp entries on an account isnt enough, there are plenty of other workarounds such as:

    Create a Distribution List and set it with an email, then set the servicedesk account as a member of the DL. Be sure to allow unauthenticated members to email the DL or external people cant send to it.


    Create another account with multiple SMTP's and set them to forward to the service account.

    Personally id go down the DL route. In fact, I would likely forgo the SMTPs on a single account in favour of multiple DL's. This makes it much easier to see individual addresses in AD/Exchange, and adding additional members into the DL as the need arises is easier too (For instance, if the Service Level Manager of Company A wants to be copied in on all emails sent from that company - you just add him into the DL's for company A, rather than screwing around with the smtps and causing headaches.
    Certifications: ITIL Foundation; MCTS: Visual Studio Team Foundation Server 2010, Administration
    WIP: None at present

Share This Page