Re: Two email domains
- From: Juha <Juha@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 3 Dec 2007 04:29:00 -0800
a Hi
Thank you for your kind answers. The client decided to order new server. As
you suggested I changed the server SW to Small Business Server. Currently I'm
thinking SBS 2003 std and 45 CALs. Hope this was good decision.
Rgs,
Juha
"SuperGumby [SBS MVP]" wrote:
inline.
"Juha" <Juha@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:615C916F-9A1F-470F-854C-41B78D009DFE@xxxxxxxxxxxxxxxx
Hi
First. This system was up and running when I started as a administrator.
Good! You can take them from a barely functioning SBS to fully functional
and become a hero in the process. I _love_ my 'inherited' sites, and mostly
they love me for just this reason, 'No-one told us we could do that' is a
common reaction at sites implemented by (I was gonna try to be nice, but
stuff it, NO) the SBS ignorant. Consider this an easy opportunity to make
yourself look like a genius.
Did I understud you correctly? They have pst-files in Central Office. If I
remove pop3 account all mails are there but the client can't send/receive
mails anywhere else but locally (if I remember this correctly).
HQ (Central Office) may or may not be storing data in Exchange regardless of
whether POP accounts are specified in the Outlook profile. In order to use
Exchange as storage mechanism they would need each PC to be configured for
both Exchange and POP and for the store location to be 'Mailbox - User Name'
rather than 'Personal Folder'. If you remove the POP account from the
profile (without 1st changing Exchange to know about the sending domain)
users will get rejected by _most_ mail servers as having invalid 'send
address' (only the SMTP .local and X400 addresses will exist) but this is
easily overcome by making Exchange implement a recipient policy in a valid
domain.
Remote clients will have Outlook 2003 or 2007 in the beging of 2008. There
could be a little cap while the system should work but clients may have
earlier version.
2003 or later is only required for RPC over HTTPS. Earlier versions of
Outlook would need to use the earlier version of 'remote connection' to
Exchange (involving VPN) and offline files (maybe, not necessarily, and also
not always desirable).
CALs. Currently they have only 5 CALs installed. I have seen maximum usage
of 6. I have recently find out that this client is intitled to utilize
School
Agreement Licenses (the cheep ones). Therefore (and some other issues) I'm
planning to migrate them away from SBS world. We have disscussed abot this
with client.
NOW I"M GONNA GET UPSET!!! WHY are you taking this perfectly suitable SBS
candidate organisation away from SBS? Explain your motivation, because there
is nothing in the proceeding paragraph but further support for maintaining
them as SBS.
Do you have links regarding RPC over HTTPS? It is propably unpossible to
join remote workers to domain.
The best instructions for setup of RPC over HTTPS are found on SBS's Remote
Web Workplace. A caution here is that the SBS must have been set up properly
and certain tasks (the to-do list) need to have been completed for the
instructions to work.
As a general description of RPC over HTTPS, can't give you a link I'm afraid
but you should be able to find discussion of such at Exchange related
websites. Best description I can give is that HTTPS (so therefore
authenticated and encrypted) is used as a transport to then cause RPC to be
available so that a 'standard' Exchange type connection is established
between the remote Outlook user and the Exchange server. This causes the
remote user to have a fully functional connection to Exchange through a
single, authenticated and encypted, HTTPS connection. ie. initiated by a
call to remoteIP:443, so therefore pretty much oblivious to firewalls which
may interfere with other style remote connections to Exchange.
Last. The client has plans to invest to SharePoint. It would be quite big.
It has to keep in mind while solving email issues.
He wants Sharepoint but you are contemplating moving him away from SBS, WHY?
P.S. After 1.1.2008 they don't wan't to use current domainname.fi
email-boxes. Still, it would take some six months until they can discard
it
totally. If I can't sell ideas mentioned here, is it possible to do this
by
current system?
SBS can do all that you have as yet indicated as required. (I might add: SBS
can do it standing on its head with _both_ hands tied behind its back, a
broken left leg and a sprained right ankle).
You have some problems though, licensing (and the associated cost of such),
implementation (an experienced SBSer would simply 'do it', and not have
needed the 3rd party services), and willingness to adopt and trust that SBS
can handle the environment you describe. Maybe some other issues about _how_
to take this crippled organisation and show them the full power of SBS.
Thanks in advantage,
Juha
Finland
"SuperGumby [SBS MVP]" wrote:
Then it appears that each Outlook client would be using POP3 individually
to
send/receive mail.
Is storage to Exchange or 'Personal Folders'? (I'm gonna lay London to a
brick nothing is being stored in Exchange)
Are all users on Outlook 2003 or later? Do you have CALs to cover all
users?
(local and remote) Keep in mind that for _any_ access to SBS (say VPN)
your
remote users need a CAL assigned anyway. _If_ you have sufficient CALs
for
all users and they use Outlook 2003 or later then the _best_ way of doing
this would be to move them fully to Exchange with remote users operating
via
RPC over HTTPS and all email stored in Exchange. Doing so gives the
business
control of access to the email, the possibility of central backup,
reduced
administration because you no longer have to maintain a 3rd party email
service, all good things, right?
"Juha" <Juha@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:83590F60-4577-424A-B29C-E9FA32AD0423@xxxxxxxxxxxxxxxx
Hi Claus
There is one problem. This client uses exchange only partially. The mx
record is not pointing to their exchange server (as far as I know).
They
use
exchange only for calender sharing. One reason for this solution, is
the
fact
that they have only 6 persons working on the site where the server is
(Central office) and over 30 persons workin separated all over the
Finland.
Those separated WorkStations are not joined into domain. Because of
that
all
Outlook Clients on the Central Office has also ISPs pop3 account
enabled
on
their Office Outlook. This pop3 account is responsible for sending and
receiving email outside domain.
The notdomainsname.fi space is registered to client.
I'll checked the default recipient policy and currently there are only
these policies:
smtp: domainname.local
X400: some stuff not related this?
the domainname.fi is not there.
Thanks in advantage.
Juha
Finland
"Claus" wrote:
Is the "notdomainsname.fi" a public domain that your client owns? If
so,
you
just add it to the recipient policy and create an A record and MX
record
for
that domain, pointing to the SBS box.
--
Claus
"Juha" <Juha@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5AEA4565-B632-4793-B8DF-6EB6A561F674@xxxxxxxxxxxxxxxx
Hi
One of my clients needs to have two email domains. There is a SBS
2003
exchange server and currently they have @domainname.fi syntax.
1. Is it possible to use in the same time @notdomainsname.fi syntax?
Where
to seek workaround?
2. If not, is it possible to change @domainname.fi =>
notdomainsname.fi
syntax? Where to find a workaround?
Thanks in advantage,
juha
Finland
- Follow-Ups:
- Re: Two email domains
- From: Claus
- Re: Two email domains
- Prev by Date: Re: Hosting a web site?
- Next by Date: Re: DNS problems
- Previous by thread: Multiple Log In Attemps on SBiz DC
- Next by thread: Re: Two email domains
- Index(es):
Relevant Pages
|
