Pages

6/29/2003

Windows 2000::Resource Kit


Some utilities can be downloaded from MS for free. However I found a spot where a lot more of them are available:
http://www.petri.co.il/download_free_reskit_tools.htm

6/25/2003

Exchange2000::SendAs Permission


From MS KB
This step-by-step article describes two methods in Exchange 2000 Server that you can use to configure a mailbox so that users other than the mailbox owner can use that mailbox to send messages.



In Exchange 2000 Server, you can permit one or more users to send messages on behalf of a particular mailbox owner by granting "Send on behalf" permissions. You can also permit one or more users to send messages as a particular mailbox owner by granting "Send As" permissions.




Grant "Send on Behalf" Permissions



If you grant a user "Send on behalf" permissions for another user's mailbox, that user can send mail on behalf of the mailbox owner. The name in the From box of these messages appears as

From: DelegateUser on behalf of MailboxOwner



where DelegateUser is the name of the user to whom you granted "Send on behalf" permissions and where MailboxOwner is the name of the user who owns the mailbox.



To grant a user "Send on behalf" permissions for another user's mailbox:

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  2. In the console tree, click Users.
  3. In the right pane, right-click the mailbox of MailboxOwner, and then click Properties.
  4. Click the Exchange General tab, and then click Delivery Options.
  5. Under Send on behalf, click Add.
  6. Type the name of the DelegateUser, click Check Names to verify the name, and then click OK.
  7. Click OK, and then click OK.
  8. Quit Active Directory Users and Computers.


For example, if you grant UserB "Send on behalf" permissions for UserA's mailbox, UserB can send messages on behalf of UserA. The From box in these messages appears as follows:

From: UserB on behalf of UserA


Grant "Send As" Permissions



If you grant a user "Send As" permissions for another user's mailbox, the DelegateUser can send mail as the MailboxOwner. The From box in these messages appears as follows:

From: MailboxOwner




To grant a user "Send As" permissions for another user's mailbox:

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  2. On the View menu, click to select Advanced Features.
  3. In the console tree, click Users.
  4. In the right pane, right-click the mailbox of MailboxOwner, and then click Properties.
  5. Click the Security tab.
  6. Click Add, and then type the name of the DelegateUser.
  7. Click Check Names to verify the name, and then click OK.
  8. Verify that DelegateUser is selected, and then click to select the Allow check box next to Send As in the Permissions list.
  9. Quit Active Directory Users and Computers.

For example, if you grant UserB "Send As" permissions for UserA's mailbox, UserB can send messages that appear to be sent from UserA. The From box in these messages appears as follows:

From: UserA


For additional information about how to grant a user "Send As" permissions in Exchange, click the article number below

281208 XADM: How to Grant a User "Send As" Rights in Exchange Server 5.5 and Exchange 2000

6/24/2003

Exchange::SMTP::TLS


I've been on an adventure the past few days setting up TLS messaging with one of our clients. I hope to document more of this experience in the next few days. Below is a diagram of message flow to and from entities external to EXCHANGE as I have it now.

W2K & Exchange Upgrade


Quoted from 101communications-news.com:

** Boswell's Q&A: At the Fork In the Exchange Migration Path

I'm moving our network from mixed to native because our Exchange
server is 15.3 G. I've read that Exchange can run in a mixed
environment -- yes or no? In one article I've read, it says that
if you are a member of the Enterprise Domain, Administrators,
Domain Admins and Exchange Admins that you will not have to run
forestprep and domainprep runs when you first try to install
Exchange 2000. Will this let me install Exchange 2000 in a mixed
environment and move mailboxes from my Exchange 5.5 SP4 server,
or will I have to be in native mode?
--Russ Moss

I want to ask you for a recommended upgrade path for Exchange 5.5
to Exchange 2000. My company is preparing to migrate to Exchange
2000 and have had varying opinions. Some say the best approach is
to install Exchange 2000 on a separate box and install the AD
connector. Others have recommended doing a full migration by
creating the Exchange 2000 box, ex-merging all mailboxes out and
importing them into Exchange 2000. Do you have a recommended
approach or is it simply a matter of preference?
-- Marty Kineen, MCSE, CCNP
Plymouth Meeting, Pennsylvania

/--------------------------------------------------------------\
| GOT A WINDOWS OR EXCHANGE QUESTION OR NEED TROUBLESHOOTING |
| HELP? Or maybe you want a better explanation than provided |
| in the manuals? Describe your dilemma in an e-mail to Bill |
| at mailto:boswell@101com.com; the best questions get |
| answered in this column. |
| |
| When you send your questions, please include your full first |
| and last name, location, certifications (if any) with your |
| message. (If you prefer to remain anonymous, specify this in |
| your message but submit the requested information for |
| verification purposes.) |
\--------------------------------------------------------------/

Russ and Marty,

Your questions are somewhat related. You both are running legacy
Exchange in a Windows 2000 domain and you're looking for the most
efficient upgrade path.

Russ, you'll need to shift your domain to Windows 2000 native mode
so that you can create Universal security groups to act as
Exchange 2000 distribution lists. This means you must either
upgrade or decommission your NT BDCs, then shift the domain to
native mode. This shift does not impact down-level clients nor
does it affect the Exchange 5.5 server.

Marty, in the configuration you've described, the upgrade path
that gets you to a full Exchange 2000 deployment with the least
hassle would be to introduce a new Exchange 2000 server into the
existing sites and use the Active Directory Connector (ADC) to
keep the legacy Exchange directory service in sync with Active
Directory during the migration. You shouldn't need to create a
separate Active Directory domain or a separate Exchange
organization. Once the Exchange 2000 server is in place, move all
the mailboxes and connectors from the legacy Exchange server then
decommission the server and shift to Exchange Native mode. The
documentation walks you through this process.

As for running Forestprep and Domainprep, it's true that both of
these actions are performed when you run Exchange 2000 Setup so
you do not need to run them separately. The documentations calls
them out individually because many organizations divvy up their
admin rights so that one account doesn't have the necessary
permissions to do both. In a single domain configuration, the
simplest way to do the ADC installation and the Exchange 2000
setup is to use the Administrator account for the domain. This
account has full access to the Schema, to the Configuration
container where the Exchange organization will be created, and
to the Domain container where the Exchange system accounts will
be created. The ADC requires a service account in Active
Directory that has Service Account Admin permissions in the
legacy Exchange organization, sites, and configuration container.

Before you can run Exchange Setup, you’ll need to install the ADC
and create recipient and public folder connection agreements to
each of your sites. You should be running Exchange 5.5 SP3 or
higher on at least one Exchange server in each site, although I
recommend getting all your Exchange servers to the latest service
pack prior to deploying Exchange 2000.

The ADC modifies the schema, so you'll need to run it using an
account that is in the Schema Admins group. Plus you'll need
admin rights for the Configuration container. The simplest way
to do this is to use the Administrator account for the domain.
When you run Exchange Setup, you’ll modify the schema again so
the same permission rules apply.

Good luck and let me know how things turn out.

Bill Boswell

6/19/2003

T1 Troubleshooting


You can really load down a T1 connection for testing by sending big pings across the wire.
The biggest ping packet I could send on my Win2K pro machine was 17799 so it was:
ping -t -l 17799 [ip dest]

I opened up about 20 of these in separate windows and pegged the line to near capacity.
During this I telenet to routers on both ends and watch the interface stats. For example,
show int s0

to watch for increasing input errors/etc.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1915.htm Cisco "Troubleshooting Serial Connections" a great document.
From this document is a section on doing extended ping testing from a Cisco router on one end in various loopback states. It shows how to use the cisco ping extended commands to send a pattern of all zeros and all ones repeated 2000 times or more.