Exchange Error: Unable to initialize the Information Store service…

Over this past weekend I ran into an issue with Exchange 2010 Service Pack 3. Even though my Exchange server’s clock was sync’d with my Domain Controller the Exchange server was unable to start the Exchange IS service, and instead was logging the error:

Event 5003: Unable to initialize the Information Store service because the clocks on the client and server are skewed. This may be caused by a time change either on the client or on the server, and may require a restart of that computer. Verify that your domain is correctly configured and is currently online.

After a few reboots, and verification that the windows clocks were actually in sync, I thought to check that the clock in the BIOS was properly configured. Since these machines are VMs on VMWare ESXi, I logged into vCenter and checked my ESXi host. Sure enough one of the three hosts was not configured to use an NTP server, and it’s local clock was off. I fixed that setting and rebooted the exchange server one more time, the server was then able to start the Information store service.

.Net 3.5 (or 2.0) Fails to install on Server 2012 R2 with Error 0x800f0906

I recently ran into an issue on Server 2012 R2 with installing .net. I could not install the feature regardless of whether or not a source was sacrificed.

I attempted to redirect the GUI wizard to install sources on DVD, but that failed.

The command line: dism.exe /online /enable-feature /featurename:NetFX3 /all /Source:D:\sources\sxs Also failed.

I finally stumbled upon a forum where a user had success by removing these two Windows Updates: KB2966826 and KB2966828 and then attempting to run the command line install again.

This worked for me very well, and i wanted to make sure this was shared, as i had been banging my head against a wall for a few hours with this one.

Installing Certificate Services, and configuring LDAPS on a SonicWALL

Assumptions: SonicOS 5.8+ and Windows Server 2008 R2 Enterprise running as a domain controller.

  1. On the Domain Controller: Open “Server Manager”, click “Roles”, click “Add Roles”.
  2. Click “Next >”, ensure there is a check mark next to “Active Directory Certificate Services”, click “Next >”, Click “Next >”, Ensure there is a check mark in the boxes “Certification Authority”, “Certification Authority Web Enrollment”, and “Online Responder” (Certification Authority Web Enrollment” and “Online Responder” are not technically needed, but are common parts of a CA infrastructure that should also be installed if you are installing a CA), Click “Next >”, Approve the installation of the IIS components that are required to run the Web Enrollment, Select the “Enterprise” radio button and click “Next >”, Select the “Root CA” radio button and then click “Next >”, Select the “Create a new private key” radio button and then click “Next >”, Select “RSA#Microsoft Software Key Storage Provider”, “4096”, and “SHA512” from the drop down boxes, click “Next >”, Edit the Common Name for the CA if desired, and then click “Next >”, Change the validity period if desired, and then click “Next >”, Click “Next >” to leave the database in its default location, click “Next >” to install IIS, Leave default IIS installation options checked, and click “Next >”, click “Install”, Click “Close”.
  3. From the Domain Controller, open Internet Explorer, and go to http://127.0.0.1/certsrv, when prompted login with the Domain Administrator account.
  4. Click the link “Download a CA Certificate, certificate chain, or CRL”
  5. Select the certificate with the common name from step 2, and then ensure the radio button “DER” is selected, click “Download CA Certificate”.
  6. Rename this certificate to match that of the common name and save it on the desktop.
  7. Login to the SonicWALL.
  8. Expand “System” from the left hand pane, and then click “Certificates”.
  9. Click “Import…” at the bottom.
  10. Select the radio button “Import a CA certificate from a PKCS#7 (.p7b), PEM (.pem), or DER (.der or .cer) encoded file.” Is selected, and then click “Browse…” Select the certificate with the common name that you set in step 2. Click “Open”, Click “Import”.
  11. Expand “Users” from the left hand pane of the SonicWALL, click “Settings”.
  12. Change the drop down box titled “Authentication method for login: “ to “LDAP + Local Users”.
  13. Ensure that the check box “Case-sensitive user names” is UnChecked.
  14. Click “Accept” at the top.
  15. Click the “Configure…” button next to the “Authentication method for login: “ drop down box.
  16. On the “Settings” tab enter the IP address of the Domain controller in the box titled “Name or IP Address:”, Change “Port Number:” to “636”, change the radio button selection to “Give login name/location in tree”, Enter a Active Directory user account( a service account with “Domain Guest” group membership will suffice) in the “Login user name:” field, enter the password for the account in the “Login password:” field, UnCheck “require valid certificate from server”.
  17. On the “Directory” tab enter the following: In the “Primary Domain:” field enter the DNS active Directory Domain Name, change the “User tree for login to server:” to the full path of where the service account (used on the Settings tab) is located in Active Directory (spaces are okay), click “Apply”.
  18. Click “Auto-Configure” to test populate the directories in AD which contain Users or Groups.

So long as your list populated with OUs you should be good, this is everything you need to do in order to secure the connection between your SonicWALL and your domain controller.

Installing SonicWALL Analyzer

Here is a quick and dirty guide to getting SonicWALL’s Analyzer software installed, configured, and displaying information about your hardware device:

  1. Download the SonicWALL Analyzer software for windows from MySonicwall.com
  2. Install using default options, and when prompted make sure to select the proper IP on the workstation/server to use to receive communications from the SonicWALL hardware device.
  3. Open port UDP 514 and UDP 162 on the Workstation/Server’s Windows Firewall to allow for Syslog and SNMP traffic to be sent to the server from the SonicWALL hardware Device.
  4. After Installation, reboot the Workstation/Server.
  5. Launch the SonicWALL Universal Management application from the start menu/desktop.
  6. Login with the default username /password of: admin/password.
  7. Set a new password for the UMH aspect of the software.
  8. Register the software with mysonicwall.com using the link at the top of the application.
  9. During the registration process, enter “ANALYZER” in the serial number field. Add a Description of the PC. Click Submit.
  10. Under the “Roles” section in the left hand pane, enter a username, password for the database and password for the database administrator. Click Update. Make sure to create a user account that IS NOT “root”, you can use anything but “root” for the database User.
  11. Under “Settings” section in the left hand pane, enter the SMTP settings necessary to send emails.
  12. On the SonicWALL, expand “Log” on the left, and then click on “ViewPoint”. Click “Add” and then enter the IP address of the workstation/server running analyzer.
  13. Install Java and flash on the Analyzer workstation/server.
  14. Attempt to log into the analyzer software now (same link as the Universal Management tool) and then you will be prompted to change your password for the analyzer user.
  15. Once Logged in, click on the “Firewall” tab at the top, then click the small button on the left to add a Hardware Device to be monitored.

This will get you up and running any analyzing traffic in real time.

Installing SonicWALL Directory Connector ( SSO Component )

This is a short and sweet mini-guide to setting up the SonicWALL Directory Connector. This should be everything that you need to get it up and running, from there you can setup the more advanced functionality, such as Terminal Services Integration on your own.

  1. Download and the SonicWALL Directory Connector for either 32 bit or 64 bit systems from mysonicwall.com
  2. Install the product with its defaults, when prompted for credentials enter a domain admin’s credentials.
  3. When Prompted to enter SonicWALL Device information enter the Internal IP of your SonicWALL, and create a shared key to be used by the SSO Component and your Device.
  4. Finish the Installer and then launch it.
  5. Now log into your SonicWALL Device and Expand “Users” in the left pane and then click on “Settings”.
  6. Under the section “Single-sign-on method:” change the drop down box to “SSO Agent” and click on the “Configure” button.
  7. On the “Settings” tab click the “Add…” button to add your agent, modify the IP, Port, and Shared Key to that of your server/workstation running the software. Click Apply. NOTE: If the status light does not turn green, you may need to add a firewall rule on the server/workstation to allow inbound connections on that port. I’ve also had to add both of these .exes to the list of excluded applications to get this software to work through the windows firewall: %ProgramFiles% (x86)\SonicWALL\DCON\CIAService.exe, %ProgramFiles% (x86)\SonicWALL\DCON\SoniCON.exe
  8. Under the “Users” tab make sure to add the Usernames of any Service accounts on the network that should be excluded from SSO reporting.
  9. Create a new Address Group on the sonicwall, and place into it all Devices that should be excluded from SSO Attempts, such as routers, switches, printers, wireless access points, basically anything that isn’t a windows PC. All of these devices will be governed by the “Default” Content Filtering Policy if CFS is in place.

Hopefully you found this helpful and it saved you some time.

Reenable a Port on Dell PowerConnect switch after BPDU Guard disable

If you’ve enabled BPDUGuard on a your endpoint facing ports (which you should do) you’ve probably asked yourself what to do when those ports auto disable themselves after a switch is plugged into them. It’s pretty simple, first remove whatever caused the port to disable, such as a loop or another switch, and then enter the following command on your power connect:

# set interface active gigabitethernet 1/0/13

Assuming that port 13 is the port you want to reactivate.

Group Policy Loopback: Merge not working on Windows 7 / Server 2008 R2

I guess I wasn’t paying attention. It’s now November 2012, and I’m just now realizing that Group Policy Loopback, with Merge selected, no longer works as I’d expect with Windows 7 and Server 2008(R2)

It used to work like this:

Replace mode would ignore all GPOs applied to the user up until it got to the OU with the loopback policy, and then apply ONLY the GPOs with user settings in the OU with the loopback policy. This still works as expected in 2008/win7.

Merge mode would ADD the additional GPOs to what was already applied to the user, overriding any existing settings as needed, effectively merging them. This is what no longer works as expected.

Here is what I’ve found:

Microsoft published this KB, 953786, which says that the PCs now need to have a entry in the ACL of the GPO allowing them to read the settings of said GPO. What I’ve done to make this easier for myself is added the “Domain Computers” Active Directory group to any GPO which contains the user settings that I wish to apply via loopback merge.

In my testing, this added ACL entry has solved the issue, and allowed it to work as I expected, which is the way that 2003/xp behaved.

Configuring Failover between two Cisco ASAs

I had to setup my first Active Passive Cisco ASA pair this past week, it turns out it’s a little simpler than the documentation first makes it appear. Here is what you’ll need:

  • Two ASAs with the licensing necessary to enable Failover
  • Two IPs on each subnet the pair will be connected to (including a new subnet on the failover link between the units, this should be a subnet not in use anywhere else on the network)
  • A Crossover cable.

Let’s make some assumptions, first let’s say our Private IP subnet is 192.168.1.x/24, our failover subnet is 172.16.1.x/24, and our wan subnet is 1.1.1.x/24, just so we know what IPs we’ll use. Let’s also assume that we’re using Interface 0/0 for the WAN, and Interface 0/1 for the LAN, and interface 0/3 for the failover.

  1. Bring your first unit online, and assign the first IP on each subnet to the proper interfaces.
  2. Bring your second unit online, and assign the second IP on each subnet to the proper interfaces
  3. Connect one of the interfaces on the first unit to that same interface on the other unit using the crossover cable, assign IPs on this interface from the new subnet you created for failover traffic.
  4. Verify that each unit can ping the other on each interface (wan to wan, failover to failover, lan to lan)
  5. Once you’ve verified that each unit can communicate with the other it’s time to start entering commands.

With those subnets in mind let’s assign IPs:

Primary:

  • Lan: 192.168.1.1
  • Failover 172.16.1.1
  • Wan 1.1.1.1

Secondary:

  • Lan: 192.168.1.2
  • Failover 172.16.1.2
  • Wan 1.1.1.2

So here are the commands that we’re going to enter on our primary unit:

  1. Interface Ethernet0/0
  2. ip address 1.1.1.1 255.255.255.0 standby 1.1.1.2
  3. Interface Ethernet0/1
  4. ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
  5. failover lan unit primary
  6. failover lan interface Failover ethernet0/3
  7. failover link Failover Ethernet0/3
  8. Failover interface ip Failover 172.16.1.1 255.255.255.0 standby 172.16.1.2
  9. failover

Here are the commands that we’re going to enter on our secondary unit:

  1. Interface Ethernet0/0
  2. ip address 1.1.1.1 255.255.255.0 standby 1.1.1.2
  3. Interface Ethernet0/1
  4. ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
  5. failover lan unit standby
  6. failover lan interface Failover ethernet0/3
  7. failover link Failover Ethernet0/3
  8. Failover interface ip Failover 172.16.1.1 255.255.255.0 standby 172.16.1.2
  9. failover

You can then run a “show failover” on each unit to see which is active, and which is standby, and whether or not failover is working. You also can continue to connect to either unit using either the primary or secondary IP, they will both display the same hostname since their configs are being replicated, but you can use the “show failover” to remind yourself which unit you are on. Finally you’ll only want to make  and save changes from the primary unit, failover will take care of replicating them to the other unit.

Once you’ve verified that everything is working, run a “write mem” on each unit before you start testing.

Windows Server 2008 R2 FTP is working internally but not through a Firewall

I ran into a problem today where a Server 2008 R2 FTP Server was working fine internally, but when you tried to access it from the internet it would not work. I checked the firewall rules, in this case a Sonicwall NSA, and the NAT and firewall rules were created properly, and they were passing traffic, but the connection was still failing.

The problem appears to be on the windows firewall, for some reasons the traffic is not making it through the windows firewall. Here is how we resolved the problem:

  1. Create a new Firewall in the Windows Firewall
  2. Allow a Program through the firewall, c:\windows\system32\svchost.exe
  3. Allow this rule for all traffic types, Public, Domain, Private
  4. Give the rule a name and click Finish.
  5. Now test again externally and you should be able to access the FTP site.