by Shijaz Abdulla
on 25.02.2013 at 23:03
You can access the Windows Azure blob storage by setting up an FTP server connected to it. For this you will need to create a Windows Azure VM running Windows (or Linux for that matter) that will host the FTP service. Each VM gets its own public IP and DNS name on the internet which you can use to access your FTP service.
In this example, I will show you how you can create a Windows Server VM on Windows Azure and configure it as an FTP server.
Besides the method described above, there are also other options such as using open source software like FTP2Azure http://ftp2azure.codeplex.com/
1. First create a Windows Server VM on Windows Azure. I used Windows Server 2012.
2. Connect via RDP to the newly provisioned VM and install the Web Server (IIS) role. Make sure you enable the FTP Server role services for the IIS role. I am assuming you already know how to add roles to your Windows Server and use the Remote Desktop client on your computer.
3. Create FTP site on IIS: Open the IIS Manager console, right click on Sites, and choose Add FTP Site. Specify the FTP Site Name and Local Path for the FTP site. Click Next. Specify binding and SSL information. Hit Next. Specify authentication options, click Finish.
This is just a test environment, so I’m just going to use the local administrator account for FTP login. Of course, in production you wouldn’t want to do that for security purposes.
4. Open a Command Prompt, use the ftp command to see if you can connect locally on port 21. (You could also use telnet)
You should get something like this:
Connected to 127.0.0.1
220 Microsoft FTP Service
5. Set External IP address on your IIS FTP server. This should be the public IP of your Azure VM service. You will find this IP listed on the right side of the VM service page on the Windows Azure Management Portal.
6. Enabling ports for FTP access on Windows Azure:
For Active FTP, you only need ports 21 and 20 to be opened. However for Passive FTP you will need to define a range of ports on the IIS FTP server and open them in Windows Azure, by defining them as “endpoints”.
a) First, define the port range on IIS using an elevated Command line using APPCMD utility, located at the System32\inetsrv in the Windows folder.
appcmd set config /section:system.ftpServer/firewallSupport /lowDataChannelPort:7000 /highDataChannelPort:7014
Then restart the IIS service.
In this example, we are defining the port range as 7000-7014.
b) Now you need to define these port numbers as endpoints on Windows Azure. You could do it manually in the Windows Azure management portal, one by one. You do this by going to Virtual Machines > [Your VM] > Endpoints. However, defining 15 points manually is rather tedious, so you can leverage PowerShell commands.
To use PowerShell, you need to make sure you download and install Windows Azure PowerShell on your computer. Before you can use PowerShell cmdlets on Azure, you need to publish the settings file for your Azure account. You can use the Get-AzurePublishSettingsFile cmdlet, which will help you download the actual settings file that corresponds to your Windows Live ID associated with your Azure account.
After you download this settings file, you can import it to PowerShell by using the Import-AzurePublishSettingsFile cmdlet and you’re good to go.
To create the endpoints, use the command:
Get-AzureVM -ServiceName ‘ServiceName’ -Name ‘FTPPortalName’ | Add-AzureEndpoint -Name ‘FTP00’ -Protocol ‘TCP’ -LocalPort 7000 -PublicPort 7000 | Update-AzureVM
Get-AzureVM -ServiceName ‘ServiceName’ -Name ‘FTPPortalName’ | Add-AzureEndpoint -Name ‘FTP01’ -Protocol ‘TCP’ -LocalPort 7001 -PublicPort 7001 | Update-AzureVM
…and so on till you’re done with the 15 endpoints…
Get-AzureVM -ServiceName ‘ServiceName’ -Name ‘FTPPortalName’ | Add-AzureEndpoint -Name ‘FTP14’ -Protocol ‘TCP’ -LocalPort 7014 -PublicPort 7014 | Update-AzureVM
Once the commands are done executing, here is what you will have in the portal now that all endpoints have been defined:
7. Configure Windows Firewall to allow FTP traffic
Open an elevated command prompt on your server and issue the following command:
netsh AdvFirewall set global StatefulFTP enable
Then, restart the FTP service.
net stop FTPsvc
net start FTPsvc
8. Test externally
From your PC, open a command prompt and attempt to connect via FTP on the your VM’s public DNS name or public IP address (details will be on the Azure portal VM service details on the right side)
If you are successfully able to connect, you are all set! Fire up your favorite FTP client and you can now use FTP to upload and download files from new VM hosted on Windows Azure.
by Shijaz Abdulla
on 25.01.2009 at 10:17
January 25, 2009
If you have enabled web-based publishing of your Offline Address Book (OAB) and your Outlook users get continuously prompted to enter their passwords, you need to check a couple of things:
- Make sure Autodiscover is working perfectly before you made the OAB change.
- Hold down the CTRL button and right click on the Outlook icon on the task bar, then select Test Email Autoconfiguration. Unselect GuessSmart and Secure GuessSmart and keep Use Autodiscover selected. On the Log tab, make sure Autodiscover is successful and that it was able to bind to an SCP.
- Make sure that the autodiscover.domain.com entry is added to your certificate’s Subject Alernative Names list.
- If you are facing problems with Autodiscover, you should correct that first before attempting the steps mentioned below.
- Make sure that you have defined the External and Internal URLs for the OAB virtual directory in your client access server.
Once you have made sure that Autodiscover is working OK, and that the credentials are being prompted for the OAB URL (and not the mailbox server), you need to check the IIS Authentication setting on the client access server.
- On the Client Access Server running Windows Server 2008, open IIS Manager console.
- Click on Default Web Site
- Open Authentication
- Note that only Anonymous Authentication is enabled. All other authentication methods should be disabled.
- Temporarily enable Windows Authentication
- Right click on Windows Authentication and choose Advanced Settings
- Uncheck Enable Kernel Mode Authentication and click OK
- Disable Windows Authentication
- Do an IISRESET
Also make sure that kernel-mode authentication is disabled for the RPC virtual directory.
Restart Outlook. You should no longer get the prompt for credentials. Test the configuration with Outlook Anywhere clients as well, if you have enabled Outlook Anywhere on your Client Access Servers.
You may need to repeat this configuration on all Client Access Servers that are enabled for Web-based publishing of Offline Address Book (OAB).
by Shijaz Abdulla
on 13.07.2008 at 13:11
If you are running Exchange 2003 and Exchange 2007 in co-existence and you have users on both systems, you will notice that, while Exchange 2007’s new OWA interface has a brand new Change Password option, the Change Password functionality for the users on Exchange 2003 has stopped working and you receive a 404 – File Not Found error.
This is because the IISADMPWD virtual directory, which was previously available on your Exchange 2003 Front-End server is no longer present on your Client Access Server. So here’s the solution:
1. If you are running Exchange Server 2007 on Windows Server 2003:
Simply enable the IISADMPWD virtual directory by following this article.
2. If you are running Exchange Server 2007 SP1 on Windows Server 2008
Things can get a little tricky here. Especially when you’ve noticed that there is no IISADMPWD folder inside the WindowsSystem32Inetsrv folder! Now what are we gonna do?! Here’s something that I’ve tried and it works:
a. Simply copy the WindowsSystem32InetSrvIISADMPWD folder from your Exchange 2003 Front End server and copy it to WindowsSystem32InetSrv folder on your Windows 2008 Exchange Client Access Server.
b. Open IIS Manager. Right click on Default Web site and choose Add Virtual Directory. Specify the alias as IISADMPWD and browse to the path of the WindowsSystem32InetSrvIISADMPWD folder.
c. Right click on the IISADMPWD virtual directory, and select the option Convert to Application.
d. Click on IISADMPWD application to select it. On the right pane, open the Authentication icon. Disable Anonymous authentication and enable Basic Authentication. Make sure only Basic Authentication is enabled.
e. Restart IIS service by using the command iisreset /noforce
Your Exchange 2003 users should now be able to change their passwords.
by Shijaz Abdulla
on 30.04.2008 at 14:13
If you have two separate Exchange Server 2007 mailbox servers, and users in one mailbox server can login to Outlook Web Access using your Client Access Server, while the users on the second mailbox server cannot log in to Outlook Web Access using the same Client Access Servers, the following might help.
This issue is seen if the mailbox server is running Exchange Server 2007 SP1 on Windows Server 2008. From Server Manager, open Web Server (IIS). Make sure the following Role services are added:
Under Application Development, select the following:
- .Net Extensibility
- ISAPI Extensions
- ISAPI Filters
- Server Side Includes
- .NET environment
Under Security, select the following:
- Basic authentication
- Windows Authentication
Do an IISRESET /noforce.
You should be able to login now. If you can’t try logging in using the domainusername format, even if you chose the option for ‘user name only’ on your Client Access Server. If you are able to log in with domainusername and not just username, and you have enabled ‘username’ only option under Forms based Authentication on your Client Access Servers, try the following.
On the IIS of your Exchange Server 2007 mailbox server, navigate to the /exchange virtual directory, open Authentication, and change the properties for Basic Authentication and enter a "" without the quotes for the Default Domain.
by Shijaz Abdulla
on 17.04.2008 at 22:06
In an earlier post, I explained how you can use Outlook Web Access (OWA) hosted on Exchange 2007 CAS Servers for accessing Exchange 2003 mailboxes in a co-existence environment by using the /exchange virtual directory.
Exchange Server 2007 CAS Servers come with Forms Based Authentication enabled by default. Now, if you wanted to disable the forms based authentication (required if you want to publish using ISA Sever 2006 Forms based authentication), OWA would still work fine internally (i.e. https://servername/exchange or /owa), as long as you choose Basic Authentication. The user will be presented with a popup password window instead of the form.
Now, what if you didn’t want users who are already logged in to the domain to be prompted for their password. The answer sounds simple – enable Integrated authentication, right?
Well, no. If you are co-existing Exchange 2003 and Exchange 2007 mailboxes and if your users have mailboxes on Exchange 2003 backend servers, and if they try to login via a CAS server using https://servername/exchange, they will receive an HTTP 404 Page not found message.
This is because ‘/exchange’ on the CAS is an Exchange 2003 virtual directory. Exchange 2007 supports Integrated Authentication only on Exchange 2007 virtual directories (see this article).
So the moral of the story is that you cannot enable Integrated Authentication on the CAS Server for the /exchange folder in an Exchange 2007 co-existence scenario. Exchange 2007 users can use Integrated authentication only if they use /owa virtual directory for accessing OWA.
by Shijaz Abdulla
on 10.04.2008 at 13:56
If you have installed Exchange 2007 Client Access Servers in your organization, and if you have installed your SSL certificates (even commercial ones) on IIS, Outlook MAPI users may receive ‘Security Alert’ messages similar to the above in Outlook.
The name on the security certificate is invalid or does not match the name of the site.
This is because of the certificate that you have installed on IIS. Outlook 2007 MAPI clients use Client Access Servers for the Autodiscover service. The Autodiscovery web service (a virtual directory on the Client Access Server) is used for automatically finding the mailbox server for a given user. When the Autodiscover service is accessed by Outlook, and the name on the security certificate installed in IIS doesn’t match the internal FQDN of the Client Access server (CAS), this error results.
Suppose your company’s public domain name is mycompany.com. You may have obtained a certificate for webmail.mycompany.com and installed on the IIS of your Client Access Server. This is correct because users on the internet will type the public name.
However, the same IIS on the CAS is hosts the Autodiscover virtual directory as well and this certificate applies. Your internal domain name might be mycmpny.local and the client access server FQDN might be CAS1.mycmpny.local. Outlooks 2007 uses this internal name to connect to Autodiscovery, and hence the mismatch error.
To fix this problem, open Exchange Management Shell and type the following commands:
Set-ClientAccessServer -Identity CAS1 -AutodiscoverServiceInternalUri https://webmail.mycompany.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “CAS1EWS (Default Web Site)” -InternalUrl https://webmail.mycompany.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “CAS1oab (Default Web Site)” -InternalUrl https://webmail.mycompany.com/oab
Set-UMVirtualDirectory -Identity “CAS1unifiedmessaging (Default Web Site)” -InternalUrl https://webmail.mycompany.com/unifiedmessaging/service.asmx
Pay attention to the text in red, you will need to change it to reflect your server’s running parameters. Recycle the MSExchangeAutodiscoverAppPool. Your users should no longer receive the security alert.
by Shijaz Abdulla
on 24.09.2007 at 08:48
I installed Windows Server 2003 Service Pack 2 on a client’s Exchange Server 2003 cluster on Thursday night (Yeah, I hear you – what a way to spend a weekend!). Everything went well, installation completed, rebooted and everything was happy and kicking.
…until on Friday morning when the Exchange HTTP Virtual Server Instance failed. Since this resource was configured to ‘affect the group’, the failure forced a failover of the whole Exchange cluster group to the passive node.
Within no time, Exchange HTTP Virtual Server Instance failed again, this time on the passive node! Someone press the Panic button!! The initial understanding of the situation was clear – Installation of Windows Server 2003 Service Pack 2 brought the mighty Exchange cluster to its knees.
I rebooted both nodes and normal operation ensued. But after a couple of hours it happened again. In the event logs, I could see things like:
Event Type: Warning
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1115
Error 0xfffffbbe returned from closing database table, called from function JTAB_BASE::EcCloseTable on table DeletedFolders. For more information, click http://www.microsoft.com/contentredirect.asp.
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services
Event ID: 1005
Description: Exchange HTTP Virtual Server Instance 100 (servername): The IsAlive check for this resource failed. For more information, click http://www.microsoft.com/contentredirect.asp.
Event Type: Error
Event Source: Srv
Event Category: None
Event ID: 2019
Description: The server was unable to allocate from the system nonpaged pool because the pool was empty. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I couldn’t find much on these errors on the Internet, and this is the reason for this post. Here’s what the problem is.
My client is running Windows Server 2003 on a 32 bit server. 32-bit versions of Windows, as we all know, support a maximum of 4 GB RAM. By default, Windows slices the total memory right down the middle: 2 GB is reserved for the OS and 2 GB for the applications. Out of the 2 GB reserved for the OS, 256 MB is reserved for non-paged pool memory.
My client is using the /3GB switch, which forces Windows to limit itself to 1 GB RAM and let the applications use 3 GB. But this causes the non-paged pool memory reservation to be reduced to 128MB instead of 256MB.
Now, 128 MB is a tight little space. IIS uses non paged pool memory for processing requests. On Windows Server 2003 and Windows Vista, IIS stops processing requests once the available non-paged pool memory goes below 20 MB. Event 2019 is evidence for that.
Of course you know, Exchange relies heavily on IIS. So that explains why the Exchange HTTP Virtual Server resource went down! But wait – what’s hogging up the non-paged pool memory? And how do we fix this?
That’s when Microsoft sent in their Poolmon utility, that grabs information on whats in there. The culprit? – Broadcom’s NetXtreme II network card driver! It was incompatible with scalable networking features bundled with Windows Server 2003 SP2 (and the Windows Scalable Networking Pack) and caused a memory leak! I disabled the TCP Chimney with the following command:
Netsh int ip set chimney DISABLED
I also disabled the registry key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersEnableTCPA registry value setting by it to zero on both nodes and other steps mentioned in KB936594. That was all it took to solve the problem!
See my earlier related post: Delayed Logins: Change Password feature in ISA 2006
by Shijaz Abdulla
on 31.07.2007 at 13:50
“Path specified cannot be used at this time”
One of my web servers running IIS 6.0 said this to me when I tried to open the Internet Information Services MMC console. It just wouldn’t let me connect to the server via the MMC console. The web sites hosted on the server were available merrily though.
All i had to do to bring the IIS console back to its working state was to restart the IIS Admin service and re-open the IIS MMC console. I guess IIS just needed a little kick to get back to work again.
Update: On 19 Dec, 2007, Microsoft released a hotfix that addresses this issue.