I am really surprised I haven't run into this before... but I guess there is a weird bug with many copiers out there that prevents scan to folder from working correctly under the following circumstances:
1) The source copier is using domain authentication
2) The source copier is trying to scan to a folder
3) The destination shared folder is on a Windows 2008 or 2008 R2 server
4) The destination server is also a domain controller
5) The destination shared folder is shared using 'authenticated users' as it's share permission, rather than specific users or the 'Everyone' group.
When these conditions are met, the scanner seems unable to scan to a folder. I found the two fixes so far:
1) Change the 'share' level permissions to 'Everyone' and 'full access'. This allows the copier to send files without authentication, thus bypassing the problem.
2) Change the user specified in the copier as the authentication account from a DOMAIN\Username or just 'Username' to their UPN format... Username@domain.suffix.
Either of those two changes seem to do the trick!
Friday, September 7, 2012
Friday, August 24, 2012
Installing and Configuring APC PowerChute Network Shutdown 3.0.1 for ESXi 5.0
I wrote this article original for ESXi 4.1 and PCNS 3.0.0, but enough has changed that I figured it warranted a new article... enjoy!
Shutting down windows servers with the APC network shutdown software is a no-brainer... but what about virtual machines? Sure, you could install the network shutdown software on every virtual machine, but that would be wasteful. Fortunately, there's a centralized way that you can shut down your virtual guests AND hosts... and the best part? It's (mostly) free! All you need is an APC battery backup unit, an APC network shutdown card, and a bunch of software. Here's what you need to do:
1) Download stuff. There's a bunch of it!
2) Install the latest network management card firmware first. It may take several shots at it... for some reason it likes to fail, but doing it over and over usually gets it going. Don't ask why.
3) Create one vMA virtual machine by extracting that zip file you downloaded and then launching the vSphere client and going to File -> Deploy OVF Template. It will guide you through what's required, but you basically need to pick a datastore for its 5GB volume. I usually make the volume 10GB for snapshot space. There are options to give it an IP, but i found that it didn't end up mattering due to the following error when trying to power on the newly created vMA:
5) Install Veeam FastSCP, then open it. Click "Add Server" and add the vMA server as a "Linux Server". Be sure to use the vi-admin username and password you specified while setting up the vMA. Uncheck the box to "Elevate account to root" as we do not have root access - it's been disabled.
6) In FastSCP, browse to the pcns300ESXi.tar.gz file you downloaded earler and right click / copy it. Note that you have to right click / copy in FastSCP, not in windows explorer... FastSCP does not have windows clipboard access built in. Once copied, expand your vMA in FastSCP, browse to the tmp folder, and paste it in the root of tmp. You can close FastSCP now.
7) Back in the vMA console, choose the option to "login", enter the vi-admin credentials, and do the following:
10) Next, you will want to configure shutdown events. Once the PCNS wizard finishes it forwards you to the PCNS configuration page. Click on "Configure Events" and configure some of the important events like "UPS: On Battery" and "Input Power: Restored". You'll most likely want to notify users for most of the events. Don't forget to check the box for "Shut Down System" next to "UPS: On Battery" and set it to go off after a reasonable amount of time on battery (this depends on how much runtime your battery has, but I usually set mine for 5 minutes. If the power is off for 5 minutes, it's most likely going to be off an awful lot longer.)
11) Also, you'll want to check the "Connected Servers" tab on the left under "UPS information" to make sure your vMA IP address is listed. If not, you'll want to add it as a client on your UPS's network management card's web page.
12) If you are using VMware HA... you have a few more steps to follow in order to get your VMs to shut down cleanly. See the following article for more details and a script that you should add to your battery event: http://nam-en.apc.com/app/answers/detail/a_id/11622/related/1/session/L2F2LzEvdGltZS8xMzQ1ODI3Njg1L3NpZC9fZG9xUXY0bA%3D%3D
In short, it has you upload the following script to your vMA, then add it as a shutdown option:
shutdownvms.sh:
13) If you are not using HA, in the vSphere client, make sure all of your ESXi hosts have their "Virtual Machine Startup / Shutdown" options configured and they are set to "Enabled", otherwise your guests are likely to just be turned off rather than shut down! (Note, this doesn't apply to HA configurations, as HA will keep disabling your shutdown options.)
That should get the system going! You can test it by, well, pulling the plug! If that's too scary for you, you can also configure the shutdown option for "PowerChute cannot communicate with the NMC", then pull the network cable from the network management card. If your hosts and guests shut down correctly, all is well!
Note: If your hosts still refuse to shut down, check out this article for a probable fix: http://nam-en.apc.com/app/answers/detail/a_id/11621/related/1. The long and short of the article is that you need to add the following line of code to the /opt/APC/PowerChute/group1/bin/shutdown file right after the line that says "export LD_LIBRARY_PATH":
Shutting down windows servers with the APC network shutdown software is a no-brainer... but what about virtual machines? Sure, you could install the network shutdown software on every virtual machine, but that would be wasteful. Fortunately, there's a centralized way that you can shut down your virtual guests AND hosts... and the best part? It's (mostly) free! All you need is an APC battery backup unit, an APC network shutdown card, and a bunch of software. Here's what you need to do:
1) Download stuff. There's a bunch of it!
- Download PCNS 3.0.1 from the APC website. It's free now, and you do not even need to register for it (finally, somebody gets it!). You can find it here: http://www.apc.com/tools/download/software_comp.cfm?sw_sku=SFPCNS301&id=127&swfam=127
- While you are there, grab the latest firmware for the APC card you are using. Make sure you know the kind of network management card you have, as the older ones are not able to use the latest firmware.
- Download the latest VMware vMA from the VMware.com website under 'tools'. As of this writing, it's 5.0.0.2-724898.
- Grab the free version of Veeam fastscp... it makes loading the APC installer on the vMA a snap. Note that fastscp is now bundled into the full backup and recovery tool... so grab that.
2) Install the latest network management card firmware first. It may take several shots at it... for some reason it likes to fail, but doing it over and over usually gets it going. Don't ask why.
3) Create one vMA virtual machine by extracting that zip file you downloaded and then launching the vSphere client and going to File -> Deploy OVF Template. It will guide you through what's required, but you basically need to pick a datastore for its 5GB volume. I usually make the volume 10GB for snapshot space. There are options to give it an IP, but i found that it didn't end up mattering due to the following error when trying to power on the newly created vMA:
- The only workaround I found for this error was to edit the newly created vMA, go to the Options tab, and under vApp Options select "Disabled". You'll get a nag screen indicating it is removing properties, but the only options that I could find set were items about DHCP, which we aren't using...
4) Open the console of the vMA, power it on, and follow the initial setup instructions. I recommend assigning a static IP as well as a real hostname to the vMA for use later. For the hostname, specify a full domain name such as VMA.domain.local. Once you are completed, you should be dropped to a blue and grey login screen.5) Install Veeam FastSCP, then open it. Click "Add Server" and add the vMA server as a "Linux Server". Be sure to use the vi-admin username and password you specified while setting up the vMA. Uncheck the box to "Elevate account to root" as we do not have root access - it's been disabled.
6) In FastSCP, browse to the pcns300ESXi.tar.gz file you downloaded earler and right click / copy it. Note that you have to right click / copy in FastSCP, not in windows explorer... FastSCP does not have windows clipboard access built in. Once copied, expand your vMA in FastSCP, browse to the tmp folder, and paste it in the root of tmp. You can close FastSCP now.
7) Back in the vMA console, choose the option to "login", enter the vi-admin credentials, and do the following:
- Browse to the tmp directory (for linux noobs, type cd /tmp) and run "gunzip pcns301ESXi.tar.gz" to unzip the file.
- In the same directory, run "tar -xf pcns300ESXi.tar" to extract the file.
- Browse into the newly created "ESXi" folder and run "sudo ./install_en.sh" to start the installation of pcns 3.0.0.
- You will likely get prompted with a warning (read it, it's funny) and need to enter your password. After that, installation starts.
- Accept the license agreement, and accept mostly defaults. When it gets to the part about java, be sure to let the installer install it's own bundled version of java.
- When you get to the part about entering an IP, just press "q" to skip it.
- Make sure you get the message about Installation has completed, and the note about how to access it - this means installation was successful.
- IMPORTANT: Make sure that the vMA is located on the last host you add to the fastpass list. This makes sure that your vMA is one of the last things shut down, and that it is able to give your final host the sutdown command, which will in turn shut down the vMA. You'll probably want to disable vMotion for the vMA too, or only map it's storage to the final host, so that it cannot be moved.
10) Next, you will want to configure shutdown events. Once the PCNS wizard finishes it forwards you to the PCNS configuration page. Click on "Configure Events" and configure some of the important events like "UPS: On Battery" and "Input Power: Restored". You'll most likely want to notify users for most of the events. Don't forget to check the box for "Shut Down System" next to "UPS: On Battery" and set it to go off after a reasonable amount of time on battery (this depends on how much runtime your battery has, but I usually set mine for 5 minutes. If the power is off for 5 minutes, it's most likely going to be off an awful lot longer.)
11) Also, you'll want to check the "Connected Servers" tab on the left under "UPS information" to make sure your vMA IP address is listed. If not, you'll want to add it as a client on your UPS's network management card's web page.
12) If you are using VMware HA... you have a few more steps to follow in order to get your VMs to shut down cleanly. See the following article for more details and a script that you should add to your battery event: http://nam-en.apc.com/app/answers/detail/a_id/11622/related/1/session/L2F2LzEvdGltZS8xMzQ1ODI3Njg1L3NpZC9fZG9xUXY0bA%3D%3D
In short, it has you upload the following script to your vMA, then add it as a shutdown option:
shutdownvms.sh:
#!/bin/shI completed this by downloading the script file they had precreated, then used Veeam FastSCP to upload the file to the /tmp directory. Once there, I changed the permissions as indicated in the instructions (sudo chmod +x shutdownvms.sh), and followed that up by moving the file to the /opt/APC folder, just so I didn't forget what it was for. After that, I just went into the "Configure Shutdown" page on the PowerChute network Shutdown web interface and entered the script and it's path in the "Run this command" box. I gave my system 300 seconds to shut everything down, which seems to be sufficient.
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/vmware/vma/lib64:/opt/vmware/vma/lib
export LD_LIBRARY_PATH
export PERL_LWP_SSL_VERIFY_HOSTNAME=0
SAVEIFS=$IFS
IFS=$(echo -en "\n\b")
hosts=(10.216.252.167 10.216.252.168)
ups_vm="vSphere Management Assistant \(vMA\)"
for host in ${hosts[@]}; do
echo $host
source /opt/vmware/vma/bin/vifptarget -s $host
for i in `vmware-cmd -l --username xxxxx --password xxxxx`; do
if [ `vmware-cmd $i getstate | egrep -c "on"` -eq 1 ]; then
echo $i
if [ `echo $i | egrep -c $ups_vm` -eq 1 ]; then
echo "Skip shut down of VMA"
else
echo "Shutting down $i"
vmware-cmd "$i" stop soft
fi
fi
done
source /opt/vmware/vma/bin/vifptarget -c
done
13) If you are not using HA, in the vSphere client, make sure all of your ESXi hosts have their "Virtual Machine Startup / Shutdown" options configured and they are set to "Enabled", otherwise your guests are likely to just be turned off rather than shut down! (Note, this doesn't apply to HA configurations, as HA will keep disabling your shutdown options.)
That should get the system going! You can test it by, well, pulling the plug! If that's too scary for you, you can also configure the shutdown option for "PowerChute cannot communicate with the NMC", then pull the network cable from the network management card. If your hosts and guests shut down correctly, all is well!
Note: If your hosts still refuse to shut down, check out this article for a probable fix: http://nam-en.apc.com/app/answers/detail/a_id/11621/related/1. The long and short of the article is that you need to add the following line of code to the /opt/APC/PowerChute/group1/bin/shutdown file right after the line that says "export LD_LIBRARY_PATH":
export PERL_LWP_SSL_VERIFY_HOSTNAME=0For linux noobs... you can edit the file by giving the command "sudo vi pathAndFileName", then pressing "i" to "insert" text... then edit the file like normal. Once you are done, press escape, then type ":" and "wq" then hit enter. Simple fix.
Sunday, August 19, 2012
Installing Dell Openmanage on an ESXi Host
Found this when paroozing the VMware communities sites for more info on Dell Openmanage for ESX.
Section 1: Install the vSphere Client and put the target host in maintenance mode
1. Connect to your Host Server via Internet address.
2. Download the vSphere Client appropriate for your version of ESXi
3. Install the vSphere Client
4. Open the vSphere Client and connect to your vCenter or directly to the host
5. Shut down all the guests on the target host, or migrate them to another host.
6. Right click on the target host in the left hand pane and click "Enter Maintenance Mode."
Section 2: Install Dell OpenManage
1. Download and install ‘vSphere CLI’ from VMware website (you will need to create an account in order to login and download the file):
http://www.vmware.com/support/developer/vcli/
Most recent at time of this post is: VMware-vSphere-CLI-5.0.0-615813.exe (https://my.vmware.com/group/vmware/get-download?downloadGroup=VCLI50U1)
2. Obtain the Dell OpenManage package for ESXi:
v4.0 OM-SrvAdmin-Dell-Web-6.3.0-2075.VIB-ESX40i_A00.9.zip
v4.1 OM-SrvAdmin-Dell-Web-6.5.0-2247.VIB-ESX41i_A01.zip
v5.0 OM-SrvAdmin-Dell-Web-7.1.0-5304.VIB-ESX50i_A00.zip
ESXi 4.0: http://ftp.dell.com/sysman/OM-SrvAdmin-Dell-Web-6.3.0-2075.VIB-ESX40i_A00.9.zip
ESXi 4.1: http://ftp.dell.com/sysman/OM-SrvAdmin-Dell-Web-6.5.0-2247.VIB-ESX41i_A01.zip
ESXi 5.0: http://www.dell.com/support/drivers/us/en/84/DriverDetails/DriverFileFormats/Product/poweredge-2950?DriverId=Y0WHR&FileId=2990390081&urlProductCode=False
3. Launch ‘vSphere CLI’ via Start > VMware > VMware vSphere CLI > Command Prompt.
4a. On ESXi 4.X, do the following:
- In the CLI window, type "cd bin" and hit enter to change the directory to the "bin" subfolder
- type "Vihostupdate.pl --server IpAddressOfHost -i -b PathToVIBinstallPackage" and hit enter.
(eg: Vihostupdate.pl --server 192.168.0.1 -i -b C:\OM-SrvAdmin-Dell-Web-7.1.0-5304.VIB-ESX50i_A00.zip)
4b. On ESXi 5.X, do the following:
- Copy the zip file containing the VIB to a datastore that the host can access. I used the vSphere client to connect to the host, then hit the configuration tab, Storage, then right clicked on the default local storage and hit "browse datastore". From that window I created a new folder named "updates" and uploaded the file into it.
- Take note of the Datastore location and name that is shown under "Datastore Details" in the bottom pane while the datastore you uploaded the file to is selected. My local store was /vmfs/volumes/502e86dd-dfa6c7f0-9ce2-0022197a5bef ...
- In the CLI window, type "esxcli --server IpAddressOfHost software vib install -d PathToVIBinstallPackage" and hit enter.
(eg: C:\Program Files (x86)\VMware\VMware vSphere CLI>esxcli --server 172.16.8.201 software vib install -d /vmfs/volumes/502e86dd-dfa6c7f0-9ce2-0022197a5bef/updates/OM-SrvAdmin-Dell-Web-7.1.0-5304.VIB-ESX50i_A00.zip)
5. The system will prompt for the username ( root - then press enter) and the root password (then press enter). The update will now be applied to the ESXi server. The update will take approx 5mins on ESXi 4, and only moments on ESXi 5. (You can view the progress on the vSphere Client screen if you have it open).
Note, you may need to enable CIM providers as well... 4.1 and 5.0 do this automatically, but I think certain builds of 4.0 require you do it manually. You can do this by opening up the CLI again and typing CIMoemProviderEnabled = 1 (thanks to a comment below for pointing this out!)
6. Once completed, close the command prompt screen and reboot the ESXi server. Once the server has come back from being rebooted, using the vSphere Client, right click on the server which is in (maintenance mode) and choose “Exit Maintenance Mode”.
Section 3: Connect to the server via Server Administrator
1. Download the latest version of Dell Open Manage Server Administrator by entering the following into your web browser:
(Version 6.3) http://search.dell.com/results.aspx?s=biz&c=us&l=en&cs=555&k=managednode%2Cv.6.3.0&cat=sup
(Version 7.1) http://downloads.dell.com/FOLDER00574377M/1/OM-SrvAdmin-Dell-Web-WIN-7.1.0-5304_A00.exe
and searching for the right package for your needs.
For windows it is:
(6.3) OM-SrvAdmin-Dell-Web-WIN-6.3.0-2075_A00.20.exe (125MB)
(7.1) OM-SrvAdmin-Dell-Web-WIN-7.1.0-5304_A00 (186MB)
2. Install Server Administrator
3. Run Server Manager and choose "Manage a Remote Node", connect via IP Address, enter in the root and root password, and ensure "Ignore Certificate Warnings" is ticked.
NOTE: If your OMSA is responding extremely slow, as mine was, and you are using the Dell Customized version of ESXi 5.0 update 1, look at this article, which details an update to fix some CIM issues. You'll need to use vSphere Update Manager to install a patch on your hosts. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2016538
Section 1: Install the vSphere Client and put the target host in maintenance mode
1. Connect to your Host Server via Internet address.
2. Download the vSphere Client appropriate for your version of ESXi
3. Install the vSphere Client
4. Open the vSphere Client and connect to your vCenter or directly to the host
5. Shut down all the guests on the target host, or migrate them to another host.
6. Right click on the target host in the left hand pane and click "Enter Maintenance Mode."
Section 2: Install Dell OpenManage
1. Download and install ‘vSphere CLI’ from VMware website (you will need to create an account in order to login and download the file):
http://www.vmware.com/support/developer/vcli/
Most recent at time of this post is: VMware-vSphere-CLI-5.0.0-615813.exe (https://my.vmware.com/group/vmware/get-download?downloadGroup=VCLI50U1)
2. Obtain the Dell OpenManage package for ESXi:
v4.0 OM-SrvAdmin-Dell-Web-6.3.0-2075.VIB-ESX40i_A00.9.zip
v4.1 OM-SrvAdmin-Dell-Web-6.5.0-2247.VIB-ESX41i_A01.zip
v5.0 OM-SrvAdmin-Dell-Web-7.1.0-5304.VIB-ESX50i_A00.zip
ESXi 4.0: http://ftp.dell.com/sysman/OM-SrvAdmin-Dell-Web-6.3.0-2075.VIB-ESX40i_A00.9.zip
ESXi 4.1: http://ftp.dell.com/sysman/OM-SrvAdmin-Dell-Web-6.5.0-2247.VIB-ESX41i_A01.zip
ESXi 5.0: http://www.dell.com/support/drivers/us/en/84/DriverDetails/DriverFileFormats/Product/poweredge-2950?DriverId=Y0WHR&FileId=2990390081&urlProductCode=False
3. Launch ‘vSphere CLI’ via Start > VMware > VMware vSphere CLI > Command Prompt.
4a. On ESXi 4.X, do the following:
- In the CLI window, type "cd bin" and hit enter to change the directory to the "bin" subfolder
- type "Vihostupdate.pl --server IpAddressOfHost -i -b PathToVIBinstallPackage" and hit enter.
(eg: Vihostupdate.pl --server 192.168.0.1 -i -b C:\OM-SrvAdmin-Dell-Web-7.1.0-5304.VIB-ESX50i_A00.zip)
4b. On ESXi 5.X, do the following:
- Copy the zip file containing the VIB to a datastore that the host can access. I used the vSphere client to connect to the host, then hit the configuration tab, Storage, then right clicked on the default local storage and hit "browse datastore". From that window I created a new folder named "updates" and uploaded the file into it.
- Take note of the Datastore location and name that is shown under "Datastore Details" in the bottom pane while the datastore you uploaded the file to is selected. My local store was /vmfs/volumes/502e86dd-dfa6c7f0-9ce2-0022197a5bef ...
- In the CLI window, type "esxcli --server IpAddressOfHost software vib install -d PathToVIBinstallPackage" and hit enter.
(eg: C:\Program Files (x86)\VMware\VMware vSphere CLI>esxcli --server 172.16.8.201 software vib install -d /vmfs/volumes/502e86dd-dfa6c7f0-9ce2-0022197a5bef/updates/OM-SrvAdmin-Dell-Web-7.1.0-5304.VIB-ESX50i_A00.zip)
5. The system will prompt for the username ( root - then press enter) and the root password (then press enter). The update will now be applied to the ESXi server. The update will take approx 5mins on ESXi 4, and only moments on ESXi 5. (You can view the progress on the vSphere Client screen if you have it open).
Note, you may need to enable CIM providers as well... 4.1 and 5.0 do this automatically, but I think certain builds of 4.0 require you do it manually. You can do this by opening up the CLI again and typing CIMoemProviderEnabled = 1 (thanks to a comment below for pointing this out!)
6. Once completed, close the command prompt screen and reboot the ESXi server. Once the server has come back from being rebooted, using the vSphere Client, right click on the server which is in (maintenance mode) and choose “Exit Maintenance Mode”.
Section 3: Connect to the server via Server Administrator
1. Download the latest version of Dell Open Manage Server Administrator by entering the following into your web browser:
(Version 6.3) http://search.dell.com/results.aspx?s=biz&c=us&l=en&cs=555&k=managednode%2Cv.6.3.0&cat=sup
(Version 7.1) http://downloads.dell.com/FOLDER00574377M/1/OM-SrvAdmin-Dell-Web-WIN-7.1.0-5304_A00.exe
and searching for the right package for your needs.
For windows it is:
(6.3) OM-SrvAdmin-Dell-Web-WIN-6.3.0-2075_A00.20.exe (125MB)
(7.1) OM-SrvAdmin-Dell-Web-WIN-7.1.0-5304_A00 (186MB)
2. Install Server Administrator
3. Run Server Manager and choose "Manage a Remote Node", connect via IP Address, enter in the root and root password, and ensure "Ignore Certificate Warnings" is ticked.
NOTE: If your OMSA is responding extremely slow, as mine was, and you are using the Dell Customized version of ESXi 5.0 update 1, look at this article, which details an update to fix some CIM issues. You'll need to use vSphere Update Manager to install a patch on your hosts. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2016538
Thursday, July 12, 2012
More on Exchange 2003 and 2010 Migration and Coexistence
A while back I made a post on migrating from SBS2003 to SBS2011, and the steps required to get coexistence working under that specific scenario, namely revolving around getting OWA redirection working. Those requirements definitely still apply here, but there were a few assumptions made based on some of the default setup work that SBS does for you. Here are some additional 'notes' about doing the same migration and coexistence without SBS factored in (So just a strait Exchange 2003 standard to Exchange 2010 standard migration.)
1) You need to configure your Exchange 2003 legacy URL. There isn't a GUI option for this... you have to issue the following command:
2) This took me a while to figure out because the fix is completely non-intuitive. Upon configuring your Exchange 2003 legacy url and testing it out, you get an "HTTP 500 Internal Server Error" with no further information. The url stops at https://(legacyurl)/exchweb/bin/auth/owaauth.dll.
To fix this you must enable FBA (forms based authentication) on your Exchange 2003 frontend server before OWA redirection will work. I found the following video showing the steps required: http://www.youtube.com/watch?v=B8NAmFqGOl4
Basically, you need to follow all the steps in my previous post, and in addition open up the Exchange 2003 management console, expand your way down to Administrative groups > first administrative group > servers > servername > Protocols > HTTP > Exchange Virtual Server, right click on the virtual server and go to properties. Under the settings tab, check the box for "Enable Forms Based Authentication" and click ok. After that, issue an IISRESET to restart your default website.
IMPORTANT: If you have only one Exchange 2003 backend server, and you configure SSL or FBA, you will likely break any activesync connections when you enable FBA. Here is an article explaining the situation from microsoft: http://support.microsoft.com/default.aspx?scid=kb;en-us;817379
Now... that seems like the proper way to go about things, but the major issue I noticed with my particular environment is that it was authentication that was broken for the mobile uses. A quick investigation of IIS after enabling FBA showed me that the 'windows authentication' option for the Exchange virtual directory was turned off. Checking the box fixed my problem! I think the only reason this worked for this particular site was because they did not have the "require SSL" box checked for the Exchange virtual directory. Not best practices, but this server will be gone soon anyway. As always, your mileage may vary. It's probably safer (or at least more supported) to follow the article I linked above.
1) You need to configure your Exchange 2003 legacy URL. There isn't a GUI option for this... you have to issue the following command:
Set-OwaVirtualDirectory -identity "Exchange2010\owa (default web site)" -Exchange2003Url https://legacy.domain.com/exchangeObviously, you should put your own server and domain name in there. This step is a no brainer... I just felt like documenting it here so that I don't have to look up the command syntax anymore. :P
2) This took me a while to figure out because the fix is completely non-intuitive. Upon configuring your Exchange 2003 legacy url and testing it out, you get an "HTTP 500 Internal Server Error" with no further information. The url stops at https://(legacyurl)/exchweb/bin/auth/owaauth.dll.
To fix this you must enable FBA (forms based authentication) on your Exchange 2003 frontend server before OWA redirection will work. I found the following video showing the steps required: http://www.youtube.com/watch?v=B8NAmFqGOl4
Basically, you need to follow all the steps in my previous post, and in addition open up the Exchange 2003 management console, expand your way down to Administrative groups > first administrative group > servers > servername > Protocols > HTTP > Exchange Virtual Server, right click on the virtual server and go to properties. Under the settings tab, check the box for "Enable Forms Based Authentication" and click ok. After that, issue an IISRESET to restart your default website.
IMPORTANT: If you have only one Exchange 2003 backend server, and you configure SSL or FBA, you will likely break any activesync connections when you enable FBA. Here is an article explaining the situation from microsoft: http://support.microsoft.com/default.aspx?scid=kb;en-us;817379
Now... that seems like the proper way to go about things, but the major issue I noticed with my particular environment is that it was authentication that was broken for the mobile uses. A quick investigation of IIS after enabling FBA showed me that the 'windows authentication' option for the Exchange virtual directory was turned off. Checking the box fixed my problem! I think the only reason this worked for this particular site was because they did not have the "require SSL" box checked for the Exchange virtual directory. Not best practices, but this server will be gone soon anyway. As always, your mileage may vary. It's probably safer (or at least more supported) to follow the article I linked above.
Wednesday, May 9, 2012
SBS 2011 and SBS 2003 Exchange Coexistence Mode
This is another nitpicky little set of steps that I always forget about and end up googling to get a solution to... so I figured I would finally write it down!
During the migration from SBS 2003 to SBS 2011, there is likely some point where you will have a number of users still on 2003, and a number of users on your new 2011 box. Wouldn't it be great if everyone could get their email, access OWA, etc etc regardless of their mailbox location, thus lessening the pressure to get everything done in one 'big bang' migration? Sure it would. Well, here's the steps (although admittedly not very detailed... just high level... individual steps can be googled for more info):
1) Follow the SBS2003 to SBS2011 migration guide from microsoft up to the point where you are ready to Migrate your mailboxes. At this point, Microsoft guides you through a disruptive cutover rather than a smooth migration, so some tweaks are needed.
2) Make sure your SSL is set up appropriately on both servers. There are a few details that are paramount in getting this right. For one, you need to have an SSL certificate on both servers. Each server must also have a unique SSL certificate, as they cannot both resolve to the same name... otherwise this won't work right. If you want to migrate your existing SSL cert from SBS2003 to SBS2011 that's fine... just make sure you remove it from 2003 at the end of it, and generate a new one (either paid, which is a waste, or using the SBS2003 "Connect to the Internet" wizard to generate a self-signed one).
3) Make sure your DNS zones are set up appropriately so that each server is resolvable by their SSL certificate name. If you followed the SBS2011 wizard, it should have done this for you automatically by setting up an authoritative zone for servername.domain.com in your internal DNS server. You should do the same for your legacy SBS2003 server and it's new SSL certificate name.
4) Go into the properties of the Exchange virtual directory under your Default Website in IIS on your SBS 2003 box and check the Directory Security tab. Hit the Edit button under Authentication and Access Control and ensure that "Windows Authentication" is checked, in addition to whatever else was already there. If it's not checked... check it! This allows the two exchange servers to pass authentication to eachother... without it, your users will get prompted for authentication twice.
5) On your SBS 2011 server, open up your Exchange 2010 management shell and enter the following command: SetVirtualDirectory "Servername\owa (Default Web Site)" -Exchange2003Url https://OldServerName.Domain.com/Exchange . That tells your Exchange 2010 server where to send OWA requests when the user's mailbox is on the 2003 server.
Done! Now, just reconfigure your firewall to send the HTTPS/SMTP/Whatever requests to your new exchange server instead of your old one, and you should be off to the races. Resume following the SBS2011 migration guide, ignoring any steps you already did!
During the migration from SBS 2003 to SBS 2011, there is likely some point where you will have a number of users still on 2003, and a number of users on your new 2011 box. Wouldn't it be great if everyone could get their email, access OWA, etc etc regardless of their mailbox location, thus lessening the pressure to get everything done in one 'big bang' migration? Sure it would. Well, here's the steps (although admittedly not very detailed... just high level... individual steps can be googled for more info):
1) Follow the SBS2003 to SBS2011 migration guide from microsoft up to the point where you are ready to Migrate your mailboxes. At this point, Microsoft guides you through a disruptive cutover rather than a smooth migration, so some tweaks are needed.
2) Make sure your SSL is set up appropriately on both servers. There are a few details that are paramount in getting this right. For one, you need to have an SSL certificate on both servers. Each server must also have a unique SSL certificate, as they cannot both resolve to the same name... otherwise this won't work right. If you want to migrate your existing SSL cert from SBS2003 to SBS2011 that's fine... just make sure you remove it from 2003 at the end of it, and generate a new one (either paid, which is a waste, or using the SBS2003 "Connect to the Internet" wizard to generate a self-signed one).
3) Make sure your DNS zones are set up appropriately so that each server is resolvable by their SSL certificate name. If you followed the SBS2011 wizard, it should have done this for you automatically by setting up an authoritative zone for servername.domain.com in your internal DNS server. You should do the same for your legacy SBS2003 server and it's new SSL certificate name.
4) Go into the properties of the Exchange virtual directory under your Default Website in IIS on your SBS 2003 box and check the Directory Security tab. Hit the Edit button under Authentication and Access Control and ensure that "Windows Authentication" is checked, in addition to whatever else was already there. If it's not checked... check it! This allows the two exchange servers to pass authentication to eachother... without it, your users will get prompted for authentication twice.
5) On your SBS 2011 server, open up your Exchange 2010 management shell and enter the following command: SetVirtualDirectory "Servername\owa (Default Web Site)" -Exchange2003Url https://OldServerName.Domain.com/Exchange . That tells your Exchange 2010 server where to send OWA requests when the user's mailbox is on the 2003 server.
Done! Now, just reconfigure your firewall to send the HTTPS/SMTP/Whatever requests to your new exchange server instead of your old one, and you should be off to the races. Resume following the SBS2011 migration guide, ignoring any steps you already did!
Monday, May 7, 2012
Allow Logon Through Terminal Services vs. Remote Desktop Users group: Which and why?
I always end up forgetting which permissions I need to grant users and where to do so when setting up terminal services... so I go googling, and end up finding the answer eventually... but I figured it's about time I left a note for myself (and others!) about which permissions you need to grant users, where they are, and why.
For starters, this article does a great job of explaining:
http://blogs.technet.com/b/askperf/archive/2011/09/09/allow-logon-through-terminal-services-group-policy-and-remote-desktop-users-group.aspx
I'll do a quick summary of the contents, though, and borrow the images in case that site goes missing at some point. All credit goes to the original poster, of course. :P
First, there's the "Allow Logon Through Terminal Services" GPO, located under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\. This policy is what controls granting access to the particular machine. When you assign this GPO to a particular machine and add a group to it, that group automatically gains rights to log on to this computer, access local resources, etc. By default, Administrators and Remote Desktop Users are assigned to this policy.
Second, there's the Remote Desktop Users group. This group, as you saw above, is already a member of the "Allow Logon Through Terminal Services" security setting on most servers by default (except for domain controllers, I believe the default domain controller policy overrides this setting allowing only Domain Admins... but I could be wrong here.). The other thing this group does is grant access to connect to the RDP-TCP service on the server. You can see/change which users and groups have access to the RDP-TCP listener by opening the Terminal Services Configuration snap in and checking the Security tab, as shown below:
Finally, here's a quick recap of the typical error messages you see, and what that generally means:
1) "To log on to this remote computer, you must have Terminal Server User Access permissions on this computer..." or "The Requested session access is denied": This error means that the user that tried to connect has been assigned to the GPO correctly for "Allow Logon Through Terminal Services", but the user is not a member of the Remote Desktop Users group, or otherwise does not have permissions to the RDP-TCP listener on that machine. Go check the Terminal Services Configuration snap in.
2) "To log on to this remote computer, you must be granted the Allow Logon Through Terminal Services right..." or "The connection was denied because the user account is not authorized for remote logon." This error is pretty strait forward... the user is not assigned to the "Allow Logon Through Terminal Services" GPO.
For starters, this article does a great job of explaining:
http://blogs.technet.com/b/askperf/archive/2011/09/09/allow-logon-through-terminal-services-group-policy-and-remote-desktop-users-group.aspx
I'll do a quick summary of the contents, though, and borrow the images in case that site goes missing at some point. All credit goes to the original poster, of course. :P
First, there's the "Allow Logon Through Terminal Services" GPO, located under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\. This policy is what controls granting access to the particular machine. When you assign this GPO to a particular machine and add a group to it, that group automatically gains rights to log on to this computer, access local resources, etc. By default, Administrators and Remote Desktop Users are assigned to this policy.
Second, there's the Remote Desktop Users group. This group, as you saw above, is already a member of the "Allow Logon Through Terminal Services" security setting on most servers by default (except for domain controllers, I believe the default domain controller policy overrides this setting allowing only Domain Admins... but I could be wrong here.). The other thing this group does is grant access to connect to the RDP-TCP service on the server. You can see/change which users and groups have access to the RDP-TCP listener by opening the Terminal Services Configuration snap in and checking the Security tab, as shown below:
Finally, here's a quick recap of the typical error messages you see, and what that generally means:
1) "To log on to this remote computer, you must have Terminal Server User Access permissions on this computer..." or "The Requested session access is denied": This error means that the user that tried to connect has been assigned to the GPO correctly for "Allow Logon Through Terminal Services", but the user is not a member of the Remote Desktop Users group, or otherwise does not have permissions to the RDP-TCP listener on that machine. Go check the Terminal Services Configuration snap in.
2) "To log on to this remote computer, you must be granted the Allow Logon Through Terminal Services right..." or "The connection was denied because the user account is not authorized for remote logon." This error is pretty strait forward... the user is not assigned to the "Allow Logon Through Terminal Services" GPO.
Friday, March 16, 2012
Assigning Trusted sites in IE via group policy preferences
Assigning sites to a user's trusted sites has always been a thorn in my side, mostly because the process for using group policies was such a pain... creating a blank profile, setting it up right, exporting it, blah blah... and to top it all off, assigning a policy prevented the user from adding any more sites to their trusted sites, making the policy settings more of a hinderance than a help.
Group policy preferences greatly enhances this process by 'adding' sites rather than enforcing only your selections. Here's a process I found off of a microsoft forum post:
1. First off create the registry entries manually, as shown below, on a reference machine. I've done this on the local machine where i need the keys to be added for all users. NOTE: The reference machine does not need to be where the keys have to be located.Manual Creation Steps:
a. launch regedit and go to: hkcu/software/microsoft/windows/currentversion/internet settings/zonemap/domains/
b.create a new key called microsoft.com. In the new key create a reg_dword(32) value called * and change the data to 2 hex.
c. repeat for any other domains the need to be trusted2. launch group policy management (again i did this from the machine where i need the keys but it is not required)
3. go to your GPO and select edit.
4. go to user preferences / windows settings / registry
5. right click registry / new / registry wizard
6. select local computer if you are on the computer where you created the reg entries and are running the GPO management gui. Otherwise choose another computer and select the reference machine from step 1.
7. the wizard will guide you through choosing the required entries, check off all required items. These entries are the ones created in step 1.
Location: hkcu/software/microsoft/windows/currentversion/internet settings/zonemap/domains//
8. Click Finish
9. You can then go back to this GPO preference and select its properties and utilize client side targeting if only certain AD groups need the values.
10. perform a replication to all DC's then a GP update /force on the machines in question; you will be asked to log out for the preferences to take. (or reboot)
Group policy preferences greatly enhances this process by 'adding' sites rather than enforcing only your selections. Here's a process I found off of a microsoft forum post:
1. First off create the registry entries manually, as shown below, on a reference machine. I've done this on the local machine where i need the keys to be added for all users. NOTE: The reference machine does not need to be where the keys have to be located.Manual Creation Steps:
a. launch regedit and go to: hkcu/software/microsoft/windows/currentversion/internet settings/zonemap/domains/
b.create a new key called microsoft.com. In the new key create a reg_dword(32) value called * and change the data to 2 hex.
c. repeat for any other domains the need to be trusted2. launch group policy management (again i did this from the machine where i need the keys but it is not required)
3. go to your GPO and select edit.
4. go to user preferences / windows settings / registry
5. right click registry / new / registry wizard
6. select local computer if you are on the computer where you created the reg entries and are running the GPO management gui. Otherwise choose another computer and select the reference machine from step 1.
7. the wizard will guide you through choosing the required entries, check off all required items. These entries are the ones created in step 1.
Location: hkcu/software/microsoft/windows/currentversion/internet settings/zonemap/domains/
8. Click Finish
9. You can then go back to this GPO preference and select its properties and utilize client side targeting if only certain AD groups need the values.
10. perform a replication to all DC's then a GP update /force on the machines in question; you will be asked to log out for the preferences to take. (or reboot)
Wednesday, February 1, 2012
SBS 2011 Remote Web Workplace "Login attempt failed" bug
Spent a few hours of my life that I never should have, figuring out this little gem. I had a freshly installed SBS 2011 server, with exchange mailboxes migrated and most of the migration wizard completed, when suddenly I noticed I could no longer use the remote web workplace to remote control any of my workstations or servers from the outside. I would get the login credentials box correctly identifying the server i was connecting to, but after entering my username and password it would come back indicating "The logon attempt failed." It worked just fine in tests earlier on, so something in the setup and migration wizard must have incorrectly tweaked something.
Turns out, it was an IIS configuration issue that appeared most likely after running the Network Preparation / Outlook Anywhere wizards. I opened IIS, expanded the default website, and inspected the authentication options for RPC and RPC with cert... both had only 'basic authentication' checked, which I was fairly certain would not work with Remote Desktop web access services. Enabling 'Windows Authentication' and performing an iisreset did the trick... but after a few minutes, it got set back to disabled! An event in the logs from "MSExchange RPC Over HTTP Autoconfig" source indicated that the settings for Outlook Anywhere had been updated, setting it back to Basic only!
The fix that eventually worked (and stuck) was to make the following change in the Exchange Management Shell:
After making that change, it may not show up in IIS right away... wait a few minutes, and that same Autoconfig service will update IIS for you, this time adding both Basic and Windows authentication. Voila!
Turns out, it was an IIS configuration issue that appeared most likely after running the Network Preparation / Outlook Anywhere wizards. I opened IIS, expanded the default website, and inspected the authentication options for RPC and RPC with cert... both had only 'basic authentication' checked, which I was fairly certain would not work with Remote Desktop web access services. Enabling 'Windows Authentication' and performing an iisreset did the trick... but after a few minutes, it got set back to disabled! An event in the logs from "MSExchange RPC Over HTTP Autoconfig" source indicated that the settings for Outlook Anywhere had been updated, setting it back to Basic only!
The fix that eventually worked (and stuck) was to make the following change in the Exchange Management Shell:
Get-OutlookAnywhere | Set-OutlookAnywhere –IISAuthenticationMethods: Basic, ntlm
After making that change, it may not show up in IIS right away... wait a few minutes, and that same Autoconfig service will update IIS for you, this time adding both Basic and Windows authentication. Voila!
Thursday, January 19, 2012
Recovering from 'Exclusive Access' rights when redirecting documents
One very useful, yet much hated, option when redirecting user documents is to "Grant user exclusive rights" to their redirected folders. If your users store sensitive or private information that not even administrators should be able to see in their folders, it's a great way to automate the process of users creating their own folders with locked down permissions upon initial logon. What happens when you NEED access to all those folders for a specific group, or for the admins? The Microsoft recommendation is to go through each folder and seize ownership, then re-apply the correct permissions... a tedious process to say the least. Well, there is a scripted way to do it that works much better (taken from http://mypkb.wordpress.com/2008/12/29/how-to-restore-administrators-access-to-redirected-my-documents-folder/):
First, you'll want to make sure that the offending GPO is turned off. It's an option under the folder redirection GPO (User configuration / Policies / Windows Settings / Folder Redirection) that needs to be unchecked, otherwise any new users will be set up with exclusive rights still.
Next, you'll need PSExec from SysInternals (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) and PowerShell installed on the server hosting the shares. Log on to your file server as the LOCAL (not domain!) Administrator. Now, create the following powershell script, and be sure to edit the $StartingDir attirbute to point to the parent folder that contains all the users' folders:
#ChangePermissions.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write
$StartingDir= "C:\Users"
$Principal="Administrators"
$Permission="F"
$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Permission.ToUpper()"."`n `
"Do you want to continue? [Y,N]"
if ($Verify -eq "Y") {
foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
#display filename and old permissions
write-Host -foregroundcolor Yellow $file.FullName
#uncomment if you want to see old permissions
#CACLS $file.FullName
#ADD new permission with CACLS
CACLS $file.FullName /E /P "${Principal}:${Permission}" >$NULL
#display new permissions
Write-Host -foregroundcolor Green "New Permissions"
CACLS $file.FullName
}
}
Save that .ps1 file to the C: drive or somewhere convenient, then open the command prompt as an administrator (right click, run as), and execute the following command:
psexec -s -i powershell -noexit "& 'C:\ChangePermissions.ps1'"
This will execute the powershell script as the local 'SYSTEM' account, which still has access to the 'exclusive' user directories, thus allowing you to modify permissions without having to seize control! Now that the LOCAL 'Administrators' group has permission to the folders, you can browse to the folders and modify permissions as you see fit. My recommendation would be to set the permissions you want on the parent folder, then just check the box for 'allow permissions to be inherited from the parent folder' so you do not have to manually add domain admins to each user folder.
Subscribe to:
Posts (Atom)