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

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

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

PTX Files

E-Transcript?
http://www.reallegal.com/DemosAndTours.asp#E-Transcript%20Viewer

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.

DHCP over Cisco Router

-configure this on the interface closest to the users.
ip dhcp-server 10.10.10.2
ip helper-address 10.10.10.2

T1 Terminology::Line Parameters

AMI = Alternate mark inversion - line coding that provides 56K channels (the other 8 K is for "overhead.")
BPV = Bipolar violation
B8ZS = Bipolar eight zero substitution = framing mechanism using intentional BPV's to encode "overhead" for "clear channel" T1's.
"Clear channel coding" = 64K channels (A T1 has 24 channels) = B8ZS
ESF = Extended Super Frame, a DS-1 framing format of 24 frames. In this format, 2 Kbps are used for framing pattern sequence, 4 Kbps are used for the Facility Data Link, and the remaining 2 Kbps are used for CRC
D4 = Fourth generation digital channel bank = "Super Frame"
DS-1 = Digital signal, level 1; 1.544 megabits per second, the North American standard = T1
Choices for T1 configuration:
- ESF or D4, if EMS choose ANSI or non-ANSI
- B8ZS or AMI
-LBO="Line Build Out" - a configurable attenuator at the CSU to adjust signal to a lower level. This may be necessary for "short" connections in which the voltage may be too high.
Resources
http://www.dcbnet.com/notes/9611t1.html Tutorial
http://www.laruscorp.com/t1tut.htm It's main topic is repeated T1 lines, but has excellent foundational materials and is very well presented.
http://www.lucent.com/livelink/162120_Whitepaper.pdf Encoding, Encapsulation, Management

Internet

TouchGraph is an interesting tool mapping website links.
http://www.touchgraph.com/TGGoogleBrowser.html

DHCP::Windows 2000::Relaying DHCP over routers

Troubleshooting a DHCP issue I came across a great discussion of DHCP in general. The discussion is about a deployment scenario for using DHCP redundantly(using the Microsoft "party line" method) over multiple subnets. Along the way it explains packet level conversation of DHCP client to DHCP relay agent to DHCP server and back and configuration of a DHCP relay agent and configuring DHCP forwarding on Cisco routers.

http://www.microsoft.com/windows2000/techinfo/reskit/deploymentscenarios/scenarios/dhcp_dhcp_config_mul_sub_env.asp

Security::Windows XP::Disable NETBIOS

This is a good thing to do. A while back I fixed issues on the home computer of a partner at our firm. He had cable internet and no firewall/etc. He constantly received NET SEND messages from a new breed of spammer. And his machine would have been wide open to attach to and run a dictionary attack.
I could not find a link to the article below since it came in an e-mail newsletter so I'm just pasting it's text here:

Step-by-Step Guide: How to block NetBIOS connections to Windows XP Pro

by Laura Hunter, SearchWindowsManageability.com contributor

The Windows server service, while indispensable on a file, print or application server, can create quite a headache when administering Windows workstations. Since the service advertises on well-known NetBIOS ports, it is a common attack vector for hackers attempting to gain access to the computers on your network.

There are a number of ways to block this avenue of attack, including implementing a central firewall or disabling the server service outright. On a Windows 2000 or XP Professional workstation, you can also create an IPsec filtering policy to stop NetBIOS traffic dead in its tracks. Follow the steps below to create an IPsec policy for an individual workstation or a central policy for an entire Active Directory domain or organizational unit.

Step 1: If you're working as part of a domain where you aren't the only administrator on staff, consult the necessary person or persons before changing any settings on a production machine. If someone has already set up group policies at the site, domain or organizational unit level, conflicting settings could spell trouble for your workstation -- causing anything from a minor annoyance to a complete inability to communicate on your network.

Step 2: Open the local computer policy by clicking on Start -> Run, then typing "gpedit.msc."

Step 3: Click on Computer Configuration -> Windows Settings -> Security Settings. Right-click on IP Security Policies on Local Computer and select "Create IP Security Policy."

Step 4: Click "Next" to bypass the initial welcome screen. Enter a name for the IPsec policy and click "Next" again.

Step 5: Remove the check mark next to "Activate the default response rule" and click "Next."

Step 6: Click "Add" to create a new security rule. A security rule consists of two key components: an IP filter list that tells Windows what sort of traffic to look for and a filter action that tells Windows what to do once it has found something.

Step 7: Create two IP filters. Both will filter traffic with a source IP address of "Any IP Address" and a destination of "My IP Address." IP filters monitor traffic according to a source and/or destination IP address, as well as source/destination port numbers. (An IP filter can only handle one type of traffic at a time, which is why security rules rely on filter lists.) One will filter traffic with a destination TCP port 139, the other will affect TCP destination port 445. This will cause the IP security rule to flag NetBIOS traffic directed against your workstation from any point of origin.

Step 8: Create a filter action to block the IP traffic affected by the IP filters created in Step 7.

Step 9: Right-click on the completed IPsec policy and click "Assign" to apply it to your local workstation.

You're done! No rebooting required. Your workstation will now reject any and all NetBIOS connection attempts. If you need to tweak the policy, you can create additional security rules to allow NetBIOS connections from administrative workstations. You can also de-assign the policy if it's not working the way you had intended.

About the author: Laura Hunter is SearchWindowsManageability.com's resident expert on management tools and solutions, storage management and network security. She has spent many years working in the trenches of network design, administration and user support, and she has earned a myriad of vendor certifications, including Microsoft Certified Systems Engineer, Certified Novell Engineer and Cisco Certified Network Associate. She is a senior systems analyst for a major American university.

Windows 2000::Disk Management

There is a good, concise, discussion of Windows 2000 disk manager at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnntpro00/html/management.asp
Dynamic disks, extending volumes on dynamic disks, mounting a volume to an empty folder on another NTFS volume are all new with Win2K and well explained in the above MSDN article.

Stupid Browser Tricks

What will your browser tell web servers about you? Try this one: http://gemal.dk/browserspy/cdrom.html That is troubling.

Check out all the rest at: http://gemal.dk/browserspy