Selva Sharing

In Windows 7, you can share files on home network easily using Home Group but creating an FTP server gives you many benefits. The FTP can also be accessed by other Operating Systems in the network, You can also configure it to be accessed from anywhere through internet. In this short tutorial, I will guide you to make an FTP Server on Windows 7 for LAN.

If your IIS is already installed then start from step 4.
Step 1
Open control panel and then click on Programs.
Step 2
In Programs, click on Turn Windows features on or off.

Step 3
After clicking Turn Windows features on or off you will see a new window. Find Internet information Services and mark check on it and then click OK button.

Use the FTP Site Wizard to Create an FTP Site With Anonymous Authentication
In this section you, create a new FTP site that can be opened for Read-only access by anonymous users. To do so, use the following steps:
1. Go to IIS 7 Manager. In the Connections pane, click the Sites node in the tree.
2. Right-click the Sites node in the tree and click Add FTP Site, or click Add FTP Site in the Actions pane.

3.When the Add FTP Site wizard appears:

1.Enter "My New FTP Site" in the FTP site name box, then navigate to the "%SystemDrive%\inetpub\ftproot" folder that you created in the Prerequisites section. Note: If you choose to type in the path to your content folder, you can use environment variables in your paths.
2.Click Next.

4.On the next page of the wizard:

1.Choose an IP address for your FTP site from the IP Address drop-down, or choose to accept the default selection of "All Unassigned." Because you will be accessing this FTP site remotely, you want to make sure that you do not restrict access to the local server and enter the local loopback IP address for your computer by typing "127.0.0.1" in the IP Address box.
2.You would normally enter the TCP/IP port for the FTP site in the Port box. For this walk-through, you will choose to accept the default port of 21.
3.For this walkthrough, you do not use a host name, so make sure that the Virtual Host box is blank.
4.Make sure that the Certificates drop-down is set to "Not Selected" and that the Allow SSL option is selected.
5.Click Next.

5.On the next page of the wizard:

1.Select Anonymous for the Authentication settings.
2.For the Authorization settings, choose "Anonymous users" from the Allow access to drop-down. Select Read for the Permissions option.
3.Click Finish.

6.Go to IIS 7 Manager. Click the node for the FTP site that you created. The icons for all of the FTP features display.

Click finish and you are done. You can now access this local FTP server from any other node of your local network. In my case the URL for the FTP is ftp://127.0.0.1

A Wikipedia entry states that only 1% of Internet data and voice traffic is transmitted through satellite links while the remaining 99% is still carried by undersea cables spread across the world’s oceans. This explains why Internet services get disrupted when these undersea cables are damaged due to passing ships or in the event of an undersea earthquake.

You should also check the recently updated Submarine Map which gives some good idea about the physical routes of these cables lying under the sea bed. This is an interactive map so you can zoom-in or click on any particular colored cable to know about their respective owners. Fascinating stuff.

In ISA Server 2004\2006 or Forefront Threat Management Gateway 2010 the “Proxy requests to published site” setting is one of the most confusing yet simple configuration options when publishing a server.

With the setting “Requests appear to come from the Forefront TMG computer,” the logic is as follows:

The request comes into TMG and TMG sends it back to the web server. When TMG does this it changes the “Source IP” address field in the IP Header to its Internal adapter IP address. When the web server sees this request (assume it’s on the same logical segment as TMG), it sees the source IP is TMG. The web server then checks its routing table and says “This address is directly accessible to me. All I have to do is ARP for this IP and if I get a ARP response, I’ll deliver it directly to that host.” The response is complete as far as the web server is concerned.

Now, with the setting “Requests appear to come from the original client,” the logic goes like this:

The request comes into TMG and TMG sends it back to the web server. When TMG does this it leaves the “Source IP” address field in the IP Header alone (i.e. the external client’s IP is maintained.) When the web server sees this request (assume it’s on the same logical segment as TMG) it sees the Source IP as someone on the Internet. The web server then checks it’s routing table and says “This address isn’t directly accessible to me. My routing table says that if I don’t have a more specific route I’ll just punt and send it to my default gateway. Let me ARP for the gateway and if I get a response, I’ll deliver it to that system”. The request is now done as far as the web server is concerned.

You can see this behavior by opening a command prompt and typing “netstat -ano” without the quotes. This command displays your current network connections. You will be able to see the internal TMG source IP address or the client source IP address depending on the setting you have in TMG.

With the setting for “Requests appear to come from original client” it is essential that the return path for the responses from the web server honor the incoming path of the request. In other words, if the request came in from TMG and this setting is enabled, then the response has to go out through TMG as well. In other words, if you select the option “Requests appear to come from the original client” you must have the web server’s default gateway set to the TMG’s internal IP address! This begs the question as to why can’t TMG’s response go out some other device for the response such as another internal router? There are two reasons for this:

1) If the other device is capable of stateful inspection, it will not have any state for the response from the web server since the original packet came in through TMG.

2) Even if that device doesn’t perform stateful inspection it most likley does NAT. As the response goes through that other device, the Source IP will get changed to the NAT device’s IP and by the time the original client gets the response, the Source IP is not who the client sent it’s request to and it will drop the response.

They say a picture is worth a thousand words and in this case a graphical representation of what is going on helps. Below are four graphs depicting the four possible scenarios.

Scenario 1: Requests appear to come from the TMG computer. Default Gateway is TMG :

The below graph shows a client request traversing through TMG with the default setting of “Requests appear to come from the Forefront TMG computer.” The default gateway of the web server is set to TMG. This configuration will work but the downside to this configuration is that the web log files will only contain the IP address of the TMG’s internal interface obfuscating the true source of the request. This is a surefire way to infuriate the marketing folks, which for some of you may actually be an enjoyable thing to do. This scenario is a safe option but totally unnecessary in my opinion. If the Web server’s default gateway is set to the TMG server then there is no reason to have the requests appear to come from the Forefront TMG computer unless you want to purposely obfuscate the IP addresses in the web log files.

Scenario 2: Requests appear to come from the TMG computer. Default Gateway is a router.

The below graph shows a client request traversing through TMG with the default setting of “Requests appear to come from the Forefront TMG computer.” The default gateway of the web server is set to another router. This configuration will work but you have the same downside to this configuration as scenario 1 in that the web log files will only contain the IP address of the TMG’s internal interface. You will typically encounter this scenario in larger enterprises where they likely have a more complex routing infrastructure and they want the TMG server’s default gateway set to a router for policy reasons.

Scenario 3: Requests appear to come from the original client. Default Gateway is TMG.

The below graph shows a client request traversing through TMG with the setting of “Requests appear to come from the original client.” The default gateway of the web server is set to TMG. This is the most common scenario and the one that I use almost exclusively. This configuration will work and the web log files will contain the client’s Source IP address. I can hear the marketing folks jumping for joy.

Scenario 4: Requests appear to come from the original client. Default Gateway is a router.

The below graph shows a client request traversing through TMG with the setting of “Requests appear to come from the original client.” The default gateway of the web server is set to a router. I’ve saved the worst scenario for last because this is the scenario where people get into trouble.  This scenario will not work because the client’s source IP address is maintained all the way to the TMG server but the TMG server forwards its response out through its default gateway breaking the chain of communication.

The question then becomes how can you maintain the client’s Source IP address in the web logs in this scenario?  The only solution that I found is by using Microsoft’s ARR (Application Request Routing) proxy-based routing module. This appears to only work with IIS 7 though.

http://blogs.iis.net/anilr/archive/2009/03/03/client-ip-not-logged-on-content-server-when-using-arr.aspx

At the beginning of this article I briefly mentioned that the default setting for publishing non-web server protocol publishing rules is for the request to appear from the original client. So, the question then becomes why is this default setting different from publishing standard website publishing rule? I came across a possible scenario which may explain the reason. When publishing the latest version of a Microsoft CRM website you must use HTTPS.  Microsoft CRM uses forms-based (or claims-based) authentication so that you log in using a secure form to gain access to your CRM website. What if you want to securely publish CRM for multiple companies using a wildcard SSL certificate? You would purchase a wildcard SSL certificate (i.e. *.example.com) and then you would create a non-web server protocol publishing rule in TMG using the HTTPS protocol. This wildcard SSL certificate then allows you to host CRM for multiple companies such as company1.example.com, company2.example.com and so on using a single HTTPS web listener. Microsoft CRM has intelligence built into the form whereby it inspects the URL that you are sending it and then depending on the URL it will forward you to the proper CRM database on the back end. This behavior only appears to function properly when you have the HTTPS rule set to have requests appear to come from the original client. If you have the other setting applied where the TMG server replaces your source IP with its IP address you will no longer get a form to sign on with but instead you will be presented with a pop-up window to logon to the domain.

In the command prompt navigate to the folder containing the PsTools.zip extracted data.

We will now launch PsExec.exe with the -i and -s switches to launch the program interactively using Local System.

psexec.exe -i -s %SystemRoot%\system32\cmd.exe

Type whoami at the newly opened command prompt and you will see that you are now running as NT AUTHORITY\SYSTEM:

You can now execute ProcDump against the process that you were previously denied access to and complete your work.

Note: If your system does not have whoami.exe, you can typically find this program as a separate download via the resource kit or support tools appropriate to your Microsoft operating system.

In the below screenshot you can see that I already ran DCPROMO on bigdog.bigfirm.biz and DNS is already configured with the DNS forward lookup zones already populated.

Note: I had the DCPROMO process automatically install and create DNS for me for this process.

Now we’re at the point where we want to add the child domain of ecoast.bigfirm.biz to the existing forest root domain of bigfirm.biz.

With Window Server 2003 you must create the DNS domain on the parent before you run DCPROMO on the child domain controller.

Therefore, right-click the bigfirm.biz DNS zone and select the option to create a new domain and then enter the domain name of ecoast. You don’t have to enter any records in ecoast.

The next step is to prepare the child domain controller in the child domain.

On srv1.ecoast.bigfirm.biz you need to point its primary DNS server to the parent DNS domain controller (bigdog.bigfirm.biz) at 192.168.2.130. If you screw-up here and point DNS to itself the child domain controller will have no way to get home to the “mothership” and report an error once you try to run DCPROMO.

There is another minor but very important procedure that you must also do on the child domain controller (srv1).

You must populate the DNS suffix box with the new domain that you are creating (ecoast.bigfirm.biz). If you don’t do this step then the child domain controller will not populate the DNS records properly at the parent DNS zone.

Once all of these procedures have been done you can now run DCPROMO on the child domain controller srv1.ecoast.bigfirm.biz.

Note: Don’t forget to allow dynamic updates on the parent DNS server (bigdog.bigfirm.biz) or else the process will fail. The DCPROMO process should warn you of this.

What I see happen a lot with Windows Server 2003 is that it takes WAY too long for these DNS records to populate at the parent. In fact, it may take upwards of 10-15 minutes or so. Don’t be surprised if you see errors in the system event log on srv1 such as this (see screenshot below). This type of problem usually auto-corrects itself but if it doesn’t you can try opening a command prompt and typing ipconfig/registerdns on srv1 to see if it can help speed up the process.

After waiting the aforementioned 10-15 minutes for replication to occur and\or after manually issuing the ipconfig/registerdns command on srv1 the DNS zone on bigdog.bigfirm.biz should now look like this:

You’ll notice that DNS is not being hosted on srv1 but is instead being hosted on the parent domain controller bigdog. What if you want to have srv1 host the DNS zone ecoast.bigfirm.biz instead? You can easily do this by a process called DNS delegation. DNS delegation can be a good idea especially if you want to reduce network traffic, provide redundancy and simplify your DNS environment. There is a great KB article on how to create a child domain in Active Directory and delegate the DNS namespace to the child domain. The KB article for this is listed at the end of this article.

From my perspective, the above procedure seems time consuming and laborious. Wouldn’t it be nice if Microsoft improved on this procedure? With Windows Server 2008 R2 your wish has come true. I get the impression that the directory services team at Microsoft took some heat for this procedure on Windows 2003.

For the below example, everything remains the same except we are now using Windows Server 2008 R2 as our operating system.

After running DCPROMO on bigdog in our forest root domain bigfirm.biz our DNS zone looks like this:

Now, here is where things get super cool. Remember all of the steps that we went through to prepare our DNS environment before we could even introduce a new child domain into the mix?

Well, prepare to be amazed.

As before with our Windows 2003 example, on srv1 make sure that you point the primary DNS server to the parent DNS server (bigdog.bigfirm.biz).

Once you do that all you have to do now is run DCPROMO on srv1!

One thing I like about the new DCPROMO with Windows Server 2008 R2 is that it automatically checks and detects that there is no DNS server authoritative for the ecoast.bigfirm.biz domain. Therefore, because it could not find an existing DNS server authoritative for ecoast.bigfirm.biz it will automatically create a DNS delegation for you. Brilliant!

Below you can see in the DCPROMO summary screen that it will automatically create the DNS delegation for you since you did not pre-create the ecoast.bigfirm.biz domain on the parent server.

After logging into srv1, DNS was installed automatically and the ecoast.bigfirm.biz DNS zone was created and populated with all of the DNS records. No errors in the event log and everything just works and works immediately.

                  Make sure you have all of the following steps in place before you setup Exchange Server 2007 on Windows Server 2008 64-Bit.
For simplicity we are assuming you are setting up a small office where one machine will be used for both the Active Directory and the Exchange Server. This setup works just fine and reduces the number of machines to maintain. If you have a larger office you may want to consider separating the Active Directory machine and the Exchange 2007 Server. 
Install Windows Server 2008 64-bit version :-
Exchange 2007 is a 64-bit application and requires 64-bit versions of Windows Server 2003 or Windows Server 2008.  You should select a computer that is capable of running the 64-bit version of Windows Server 2003 or 2008.  For this example we will start with a clean installation of Windows Server 2008 64-bit version that has not had any roles installed.
After installing Windows Server 2008, we set the clock and the name of the server to be "EX2007".  At this point this server is configured to be a stand-alone computer with default settings.


Configure Your Static IP Address :-
The default installation of Windows 2008 sets your IP v4 and IP v6 addresses to use DHCP.  Since we will be configuring this computer to be a domain controller, you must change the IP address of the computer to be a static IP address.
To change your IP address, click on "View Network Connections" in the Server Manager screen. 
This will display the list of active network interfaces.

Highlight "Internet Protocol Version 4 (TCP/IPv4)" and press the Properties button.

Change the radio button to "Use the following IP address" and enter an IP address you want to use for this server.  In our example, we chose to assign this server the internal IP address "192.168.1.25".  We also have a firewall appliance that operates as a gateway at the IP address "192.168.1.1".
 
NOTE: It is important to include this computer in the DNS list.  You should list the IP address of this computer as the first entry in the list of DNS servers.  In the "Alternate DNS server" field, enter the IP address of a DNS server provided by your ISP.

Press OK to save your changes.

Now you will need to modify the support for IP v6.  If your network uses IP v6, then you will need to select "Internet Protocol Version 6 (TCP/IPv6)" and press the Properties button.  Enter a static address.  If you are not using IP v6, you can leave the IP v6 set to the default setting of DHCP.

NOTE:  Exchange requires that IP V6 be enabled.  Even if you do not use IP V6 you must leave it enabled.  During the setup of Active Directory, the Active Directory Setup Wizard will check that both IP v4 and IP v6 have static addresses as long as the IP v4 address is static you can continue the installation.  DO NOT DISABLE IP V6 or else the Exchange Hub Transport Service will not start.
At this point you should have all IP addresses on this server configured as static IP addresses.  OR you have the IP v4 address configured as static and the IP v6 configured using DHCP.  Press OK to save your changes and close the network connection screen.
Activate Auto Update :-
The next step in making this server a domain controller is to activate auto update.  Active Directory will not install until this computer has auto updates active.  To activate auto updates click on the link "Configure Updates".   Then select the option to have Windows automatically install updates.   At this time Windows will download updates and will most likely need to reboot your computer.  Allow the updates to be applied and the computer to be restarted until all updates are applied before installing Active Directory.  You do not want to be in the middle of installing Active Directory when an auto update needs to reboot your computer.

Add role - Active Directory Services :-
The process of installing Active Directory consists of two steps, the first step is to install Active Directory and then you will need to configure your Active Directory.  Once this is complete your Windows Server will now be a domain controller.
Step 1 - Install Active Directory
At the Computer Management Screen press the "Add Roles" link.  At the Select Server Roles dialog check/tick the option "Active Directory Domain Services" and press Next.
Active Directory Domain Services will present information about the changes it will make to your server.  Review this information and press Next.
Now the installation will scan your configuration and inform you if there are any pre-requisites that you have not fulfilled.  If the Active Directory Installation presents an errors, correct these at this time and then repeat the installation.  Once the Setup program indicates that you have met all pre-requisite, then  press the Install button to start the installation process.
The setup program will now install Active Directory on your Server.
When the installation is complete you should see a message indicate "Installation Succeeded", press Close to return to the Server Management Screen.
Step 2 - Configure Active Directory
At the Server Management screen you should now see that you have 1 role installed.  The Active Directory Domain Services may indicate that it is installed but there are errors.  This is because the software is installed but not configured.
To configure Active Directory click on the line under Roles labeled "Active Directory Domain Services".  The Server Manage will show you a page about the status of the Active Directory Role.
Click on the link "Run the Active Directory Services Installation Wizard (dcpromo.exe)" and the Active Directory Domain Services Installation Wizard will appear, press Next.
The Installation Wizard will present information about the version of Active directory, press Next.
Since we are assuming this Exchange Server will be the first Domain Controller, we chose to create a new domain in a new forest.  Press Next.
Enter the name of your domain.  The domain name you enter here is the domain name that Exchange will associated with all of your email.  If you use a hosting company to host your Internet Domain, then you may want to enter the name of your Internet domain with ".local".  If you host your own Internet Domain then you would enter your domain name here.
In our example we are assuming that IGetMail.com is hosted at an Internet Hosting Company.  Since we do not host IGetMail.com on this Exchange Server, we will use IGetMail.local to indicate our internal domain for IGetMail. 
NOTE:  Once you enter your domain name it is very hard to change it in the future, so you should take great care when enter this name. 
Press Next once you have decided on the name of your internal domain, that will be your Active Directory Domain and the domain serviced by Exchange.
Next the Installation Wizard will ask you about compatibility.  If you plan to have domain controllers running various versions of Active Directory then you will want to chose a function level to include the lowest version of Windows that you are using for domain controllers.  Press Next.
Next you will be asked a similar question which is at the domain level instead of the forest level on the previous screen.  You should follow the same approach and include the function level to include the lowest version of Windows you plan to use for domain controllers.  Press Next.
The first Domain Controller needs to have a DNS server running locally.  The optimal location is to start out with having the installation wizard install the DNS server locally.  Also it will automatically make this computer a global catalog server.  Press Next.
You can specify where you want Active Directory to store its data.  If you only have on e drive in your Server then use the defaults.  If you have multiple drives, you can select which drive to use.  Press Next.
Should you need to restore Active Directory in the event of a hard drive failure you will need to boot your Server into a special mode called "Directory Restoration Mode".  Should you need to boot your computer into this special mode, you will need to use a special password just for this restoration.  You can define this password at this time.  NOTE:  This password is different than the administrator account and if you change the administrator password this password will not change.  So you will need to store this password forever in a safe place.  Press Next.
Now the Installation Wizard will summarize the configuration that it is about to create.  Press Next to start the process of configuring your new Domain Controller.
The Installation Wizard will show its progress as it configures your Server.   This will take a long time.
When the installation is complete, you will be shown a final screen.  Press Finish.
Then restart your computer.
After restarting your computer Windows should show you the Server Manager.  You should see on the Server Manager screen that you have Active Directory and DNS Server roles installed.  Also the process of installing Active Directory will add the features "Group Policy Management" and "Remote Server Administration Tools".
Add role - Active Directory Lightweight Services
Now that have your Server configured for Active Directory, Exchange requires that you add the Lightweight Service.  NOTE Exchange only requires that the Lightweight services are installed but does not require the services to be configured. 
Click on the link "Add Roles" and then select to add the role "Active Directory Lightweight Directory Services" and press Next.
The installation wizard will inform you that it will make the following modifications to your server, press Next.
Then the installation wizard will confirm your intention, press Install to begin.
The installation wizard will show its progress.
And finally when the role has been installed, the installation wizard will show its results.  Press Close and then proceed to configure this newly installed role.
At this point your Server Manager should show you that you have the Active Directory Lightweight Directory Services installed.  This is sufficient for Exchange.  If you want to create LDS instances you are welcome to but that task is not required by Exchange.
Add feature - Windows Process Activation Service
The next feature that Exchange needs installed sis the Windows process Activation Service.  To install this feature click on the link "Add Features".
At the Select Features screen, check/tick the feature "Windows Process Activation Service".  Then select the items under this service and press Next.
Confirm your selections and press Install.  Windows will now install this feature and when it is complete, press Close to return to the Server Manager.
Add role - Web Server (IIS)
The next Role that Exchange needs installed is the Web Server IIS.  To install this role, at the Server Manager click on "Add Roles".
At the Select Server Roles screen, check/tick the role "Web Server (IIS) and press Next.
The Web Server IIS installation will present information about what it will perform, press Next.
Exchange requires that several additional services be added to the default settings in IIS. 
Check / Tick the following additional service in additions to the default settings:

• Security - Basic Authentication
• Security - Windows Authentication
• Security - Digest Authentication
• Performance - Dynamic Content Compression
• Management Tools - IIS 6 Management Compatibility (include all items under this service).

Then press Next.
The Web Server installation wizard allows you to verify your selections, press Install to begin.
The installation wizard will now install IIS on your Exchange Server.
When IIS is installed, press Close to return to the Server Manager.
Add feature - PowerShell
Now you are ready to install the last feature that Exchange requires as a prerequisite.  At the Server Manager click on "Add Feature".
Select the Feature "Windows Power Shell" and press Next.
At the installation confirmation screen, press Install to begin the process of installing this feature.  When the Power Shell feature is installed press close to return to the Server Manager.
Your server should now be ready to install Exchange 2007.
Roles / Features NOT to install
Exchange has a requirement to use its own SMTP service and not the SMTP Role that is built into Server 2008.  As a result you must not install the SMTP feature from the Server Manger.  This will be installed by Exchange.  Note that the Exchange Setup wizard will issue a warning that the SMTP services are not already installed, yet if you install the Windows 2008 SMTP feature, the Exchange Setup will consider that an error.


Installing Exchange Server 2007
You are now ready to install Exchange Server 2007.  Run the Exchange Server 2007 setup and click on the link to Install Microsoft Exchange Server 2007 SP 1.
The Exchange Server 2007 setup wizard will present information about the task it will perform, press Next.
Accept the license agreement and press Next.
You can choose to participate in error reporting if you wish, press Next.
Since this is Exchange Server is intended to be our only Exchange server we will chose the typical installation which installs all of the components to make this Exchange receive, store and send email.  Select Typical Exchange Server Installation and press Next.
Enter the name of your organization, typically this corresponds to your company name or domain name.  Press Next.
If you intend to use Outlook 2003 clients to connect to this Exchange Server, then chose Yes to provide compatibility with these clients, then press Next.
Exchange will now verify that all prerequisites are met.  If there are any items that Exchange needs, it will inform you at this time.  If the prerequisites have all been met, then press Install to begin the installation.
When the Exchange Server 2007 installation wizard completes, it will show the results of installing each component within Exchange Server.  You should see all components with a green check mark.  Press Finish and your Exchange Server should now be ready to use.
Since Exchange Setup modifies your Active Directory settings, it is a good idea to reboot the server once the installation is complete.
Allow IGetMail access to your Exchange Server
IGetMail Version 3.x instructions:
When you are running IGetMail version 3.x you can instruct IGetMail to send email to your Exchange server using an authenticated user or anonymous access.
Authenticated User Access - With this method you instruct IGetMail to use a specific Exchange user account to connect to the Exchange Server.  Once connected through this account, IGetMail can send email to any of your Exchange user accounts.  In order to use this method, the Exchange user account must be a member of the Exchange Server Group within Active Directory.
To setup Authenticated Access:

1. Open the Exchange Management Console
2. Expand "Server Configuration"
3. Select "Hub Transport"
4. In the middle section of the Management Console you will see the list of Receive Connectors.

1. Right click on the Receive Connector "Default ServerName" and choose Properties
2. Select the "Authentication" tab.
3. If you do not have an SSL certificate from a third party SSL provider, then Uncheck / Untick the option "Offer Basic authentication only after starting TLS".  By default Exchange will not allow users to authenticate until you have an SSL certificate.  Unchecking / Unticking "Offer Basic authentication only after starting TLS," allows Exchange to offer Authenticated login over standard SMTP.

When you configure IGetMail you will need to specify a Windows user that meets these two requirements.

• The Windows account must have a mailbox in Exchange
• The Windows user must be a member of the group "Exchange Servers"

Commonly the Administrator account does not work because it does not have a mailbox and a standard Windows account is normally not a member of the Exchange Server group.  To solve this you can either give the administrator a mailbox or in our example below we created a Windows user, made this Windows user a member of the "Exchange Servers" groups, and created a mailbox for the user.  In our example this new Windows user is named "IGetMail".

1. Run Active Directory for Users and Computers.
2. Select the Users group in the column on the left.
3. Right Click and add a new user.  In our case we choose to name this new user "IGetMail" since we will use this Windows user account to route the email through as the email is delivered to all of the other users within Exchange.

1. Select the Window user account that you want to have IGetMail use to connect to your Exchange Server.  Right click on the user name and choose Properties.
2. Go to the "Member Of" panel.
3. Press the Add... button.
4. Add the Group "Exchange Servers" to make this Windows account a member of the "Exchange Servers" group.  This will grant this Windows account the rights to route email to other users.  This is needed for IGetMail to route email to your users.

Next we need to add a mailbox to the Windows account that IGetMail will use for authentication.

1. Run the Exchange Management Console
2. Expand "Recipient Configuration"
3. Select Mailbox to show a list of existing Exchange Users
4. Right Click on "Mailbox" under "Recipient Configuration" and select New Mailbox or Click on New Mailbox in the Actions Column on the right hand side.
5. Add the Windows account that you want IGetMail to use to the list of Exchange users. In our example below we have added the account "IGetMail" to the list of Exchange Users.

Now Run IGetMail

1. At the Status Panel, press the "Modify SMTP Settings" button.
2. Check / Tick the option "Authenticate as - "
3. Enter the Name of a Windows User Name that you want IGetMail to use to connect to the Exchange Server.  This Windows account must have a mailbox in Exchange and must be a member of the "Exchange Serves" group.

IGetMail is now configured to send email to your Exchange Server. 

To Setup Anonymous Access:
Anonymous access - With anonymous access you can allow anyone to send email to any of your users.  In this case IGetMail only has to connect to the Exchange Server, it does not need to log into a Windows Account.
To configure Exchange to allow any user to route email perform these steps:

1. Open the Exchange Management Console
2. Expand "Server Configuration"
3. Select "Hub Transport"
4. In the middle section of the Management Console you will see the list of Receive Connectors.

1. Right click on the Receive Connector "Default ServerName" and choose Properties
2. Select the "Permissions Group" tab.
3. Check / Tick "Anonymous Users"
4. Save your changes.
5. Now anyone can connect to the Exchange Server and route email to any user.

IGetMail Version 1.x and 2.x instructions:
When you are running IGetMail Version 2.x and 1.x you need to allow anonymous SMTP connections for your server.
Method 1 - Run the Exchange Management Console.  Expand the Server Configuration and select Hub transport.  In the lower half of the screen under the tab "Receive Connectors" right click on the connect labeled "Default <Name Of Your Server>" and select Properties.  At the Properties for the default server select the Permissions Group tab.  At the Permissions Group Tab, check / tick the option Anonymous and save your changes.
 
Method 2 - Run the following management shell command (note this is the Exchange Management shell and not the PowerShell):

Set-ReceiveConnector -Identity "Default <ServerName>" -PermissionGroups "AnonymousUsers"
Where you would replace <ServerName> with the computer name of this server.

Adding E-Mail Users :-
Run the Exchange Management Console.  Expand the item "Recipient Configuration" and select Mailbox.
Click on the option "New Mailbox" in the right hand panel under the Actions column heading.
Proceed through the wizard to create each of your new users.