The Service Fails to Start: The service did not respond to the start or control request in a timely fashion

During a recent deployment it was noticed that the DirSync and ADFS 2.0 servers were showing the following error in the Event log which stopped me from proceding with the installation

The Service Fails to Start: “The service did not respond to the start or control request in a timely fashion –  Event ID 7000 – The response has taken longer than 30,000 milliseconds to respond.

Looking at various factors and elimating them was a tideous task such as:

Has the server enough resources – Yes

Any issues with DC’s – No

Any issues with Firewall’s/Proxy for internet connectivity – No

Any issues with the hypervisor – No

So based on this I stumbled across the following fix which allows you to increase the timeout:

Increase the default timeout value:

  • Start Registry Editor (Regedit.exe).
  • To change the value data for the ServicesPipeTimeout DWORD value to 60000 in the Control key, follow these steps:
    1. Locate and then click the following registry key:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
    2. Click the Control subkey
    3. Right-click the ServicesPipeTimeout DWORD value, and then click Modify.
    4. Click Decimal.
    5. Type 60000, and then click OK.
  • If the ServicesPipeTimeout value is not available, add the new DWORD value, and then set its value data to 60000 in the Control key. To do so, follow these steps:
    1. Locate and then click the following registry key:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
    2. Click the Control subkey.
    3. On the Edit menu, point to New, and then click DWORD Value.
    4. Type ServicesPipeTimeout, and then press ENTER.
    5. Right-click the ServicesPipeTimeout DWORD value, and then click Modify.
    6. Click Decimal.
    7. Type a value of 60000, and then click OK.
      The value is 60000 milliseconds and is equivalent to 60 seconds or to one minute.

    Note This change does not take effect until the computer is restarted.

And viola as if by magic on the next pass no issues were observed. To date it would just seem that the server did not respond in a timely fashion and by increasing this gave us more time for it to succeed.

Advertisements

Powershell to set or retrieve additional attributes

I recently worked on a project where the customer had an immense amount of AD objects but only actually had a small smaller subset of users they wanted to license but did not fully want to expose AD dumps to create a list of users to license and trawling though these users in a web console would be laborious  So wanted to populate one of the fields mentioned in this KB article http://support.microsoft.com/kb/2256198 to identify who should be licensed on mass.

Once the DirSync had completed we were left with the task to export this information out of the portal which would be PowerShell now the interesting piece is the following:

If you use the MOP with the Get-MSOLuser commands even though you can run the command to get attributes it always returned blank. It turned out that the get-msoluser command’s ONLY show what you can see in the web portal not the underlying Active Directory.

So to get around this if you log on to the Exchange PowerShell commands you can get to all the information in the underlying Office 365 AD using the get-user command and can run an export with all the information.

Exchange 2010 Mailbox Migration Fails with The socket connection aborted

If you are trying to migrate a Mailbox from on premise to Office 365 and see the following error:

The DataImportTimeout property may be set too low as by default it is set to 60 seconds and can be set up to 30 minutes. You may find that the migration may have started as depending on where the commuication failed the move request may have been processed.

To resolve this:

To isolate the issue, you may check how it works if you increase the timeout with the following steps:

  • On the Client Access server, open the following file with a text editor such as Notepad:

\ExchWeb\EWS\web.config

  • Locate the following section in the web.config file:

<!– Mailbox Replication Proxy Server configuration –>

<MRSProxyConfiguration

IsEnabled=”true”

MaxMRSConnections=”100″

DataImportTimeout=”00:01:00″ />

  1. Make sure value of the IsEnabled property is set to true.
  2. Check the value of the DataImportTimeout property. The minimum value is one minute (00:01:00), and the maximum value is 30 minutes (00:30:00).
  3. Set a higher value, but make sure the value is less than 30 minutes.
  4. The recommended value for this field should be 00:20:00 (20 minutes).
  5. After the values are configured correctly, save and close the web.config file.
  6. Restart IIS

Wildcard Autodiscover Outlook Client Warnings

If in your setup your external email domain is customer.com but your internal domain is customer.net for example unless the wildcard certificate contains the internal *.customer.net as well the clients will warn that the server cannot be trusted this is due to the fact that the certificate does not have the relevant information. But before you go away and purchase the additonal SAN’s on the wildcard certificate there is a work around for this using Exchange PowerShell:

Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri https://cas.customer.com/Autodiscover/Autodiscover.xml

Set-WebServicesVirtualDirectory -Identity “CASServer\EWS (Default Web Site)” -InternalURL https://cas.customer.com/EWS/Exchange.asmx -BasicAuthentication:$true

Set-OABVirtualDirectory -Identity “CASServer\OAB (Default Web Site)” -InternalURL https://cas.customer.com/OAB

Note: You must ensure that you enable SSL on the OAB directory in IIS which is not on by default. The above command will only enable SSL, but will not ensure 128-bit SSL is required.

Enable-OutlookAnywhere -Server CASServer -ExternalHostname “cas.customer.com” -ClientAuthenticationMethod “Basic”-SSLOffloading:$False

As by default the URL’s will be the server names with the .net or .local whichever you have internally.

This will resolve those issues for you!

Exchange 2010 OWA Redirects

If you are in the process of migrating from earlier versions of Exchange such as Exchange 2003 to Exchange 2010 or even to Office 365 URL redirects is a very useful setup to allow a single URL to re direct to multiple locations depending on where users are hosted.

To enable the re direction of 2003 OWA on the 2010 Exchange server open PowerShell and run the following command:

Set-OwaVirtualDirectory “OWA (Default Web Site)” -Exchange2003Url https://mail.customer.com/exchange

Also depending on customer requirements you can also configure the OWA redirect so all users go to https://owa.customer.com and get re directed accordingly to either https://owa.customer.com/owa or https://mail.customer.com/exchange. To re direct all the traffic in the 2010 Exchange go to the IIS MMC and set as shown below:

Warning: It’s very important that you check the checkboxes exactly as shown in the screenshot above!

Once this step is complete, you need to remove the enforced redirect from each of the virtual directories under the Default Web Site. To do this, select each virtual directory individually, and then open the HTTP Redirect property and uncheck the “Redirect requests to this destination” checkbox. You’ll need to do this on the following virtual directories:

  • aspnet_client
  • Autodiscover
  • ecp
  • EWS
  • Microsoft-Server-ActiveSync
  • OAB
  • PowerShell
  • RPC

If the customer wants to browse http://cas01.customer.com, you’ll get an HTTP 403.4 error at this stage. This is because SSL is required at the top-level website. In order to get the redirect working, we need to disable SSL for the toplevel website while leaving it enabled for the relevant child virtual directories.

Select the Default Web Site and open the SSL Settings properties. Uncheck the Require SSL checkbox as shown below:

Like the redirection settings, this change will be inherited down the tree for any virtual directory which does not explicitly set the setting independently. Ensure that SSL is required for the following virtual directories:

  • Autodiscover
  • ecp
  • EWS
  • Microsoft-Server-ActiveSync
  • OAB
  • owa
  • Rpc

Warning: If you require SSL for the PowerShell virtual directory, you will render Remote PowerShell inoperable!

Once you’ve configured the redirection and SSL settings, open a command prompt and run iisreset.

Firewall Ports for Office 365

I have been asked many times for the port information and tried many ways to try and portray this in a manner which is simple to understand. For further URL’s IP’s please review the following Microsoft information – https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2?ui=en-US&rs=en-US&ad=US#BKMK_Portal-identity. I will maintain the separate workloads from this blog but it sometimes it is not always kept up to date 100%!

Server/Service Port Protocol Direction
ADFS   (Internal) 443 TCP Inbound/Outbound
ADFS (Proxy DMZ) or WAP Server 443 TCP Inbound/Outbound
Microsoft Online Portal (Website) 443 TCP Inbound/Outbound
Outlook Web Access (Website) 443 TCP Inbound/Outbound
Lync/Skype for Business Client 443 TCP Inbound/Outbound
SharePoint Online (Website) 443 TCP Inbound/Outbound
Outlook for Mac 443 TCP Inbound/Outbound
Outlook Client 443 TCP Inbound/Outbound
Mail Routing 25 TCP Inbound/Outbound
SMTP Relay (requires TLS) 587 TCP Inbound/Outbound
Simple IMAP4 migration Tool 143/993 TCP Inbound/Outbound
POP3 (requires SSL) 995 TCP Inbound/Outbound
DirSync/Azure Active Directory Connect 80/443 TCP Inbound/Outbound
Exchange Migration Tool 80/443 TCP Inbound/Outbound
IMAP Migration Tool 80/443 TCP Inbound/Outbound
Exchange Management Console 80/443 TCP Inbound/Outbound
Exchange Management Shell 80/443 TCP Inbound/Outbound
SfB (Data Sharing Sessions) 443 TCP Outbound
SfB (Video, Audio, Application Sharing) 443 TCP Outbound
SfB (Audio & Video) 3478 UDP Outbound
SfB (Audio & Video) 50000-59999 TCP/UDP Outbound
SfB/Lync Mobile Push iOS Only 5223 TCP Outbound

It should be noted that 3rd party certificate revocation will be required which is carried out normally anonymously on port 80 so any proxies/firewalls routing the traffic should expect this. Depending on your provider you may be able to get the CRL URL in advance but for Office 365 this is not as simple.

Office 365 Delegated Administration

Within your partner tab in Office 365 you are able to manage tenancies on behalf of your clients. With this also comes the ability to do this via PowerShell as well but with limitations such as Exchange Online can’t be managed via this process, so to do this you need a seperate unlicensed admin account created to do this.

As you should all be familar with the web GUI I will discuss the required PowerShell commands to get started.

Once you have connected your service use the following cmdlet:

$tenID=(get-msolpartnercontract -domain customer.com).tenantId.guid

Then to get all users for example use:

get-msoluser -tenantID $tenID

all the other commands such as set-user are avaliable just ensure you include -tenantID $tenID to any commands!

OCS Federated IM’s only working one way

Recently after implementing my Edge services in OCS we started to federate with our partners and all seemed rosy to start off with. Then all of a sudden we could only send IM’s out and could not receive any back. External partners would send us an IM we would get the OCS toast but when you accept it the conversation was blank.

Well after much checking and doubling checking everything!!! It turned out that the primary EDGE certificate that had our domain name was the incorrect way around as our users SIP address end in a different domain name. So if anyone else is working in a multi domain environment make sure the primary name or your certificate is the same as your users SIP address!