Sunday, September 18, 2016

0x80190194 OAB Error when Migrating to Exchange 2016

When migrating from Exchange 2013 to Exchange 2016, I encountered an error 0x80190194 when downloading the Offline Address Book on workstations.

0x80190194 The Operation Failed

 
0x80190194 is a very common error when downloading the OAB and there are many server side problems which can generate this error.

Exchange 2013 by default had the servers responsible for the Offline Address Book hard coded as a Virtual Directory as shown below.


In Exchange 2016, by default we no longer want to hard code the Virtual Directories and instead enable GlobalWebDistribution which allows the Autodiscover service to automatically select the best Virtual Directory for the distribution request.

To set this up, we want to ensure the VirtualDirectories attribute for each Offline Address Book is set to $null.  We also want to ensure GlobalWebDistribution is enabled so that Autodiscover can take care of it.

This is done with the following command.

Get-OfflineAddressBook | Where {$_.ExchangeVersion.ExchangeBuild.Major -Eq 15} | Set-OfflineAddressBook -GlobalWebDistributionEnabled $True -VirtualDirectories $Null

Following this, perform an iisreset.

The Offline Address Book now downloads correctly again on Exchange 2016.

Need IT Support in Perth?  Contact Avantgarde Technologies now.

Thursday, September 15, 2016

Bug Creating Frontend Transport Receive Connectors in Exchange 2016 CU2

There is a bug creating Frontend Transport Connectors from Exchange Administrative Center in Exchange 2016 CU2.

Currently it is not possible to select Hub Transport or Frontend Transport when creating a new connector as the option is greyed out.


In Exchange 2013, it is possible as shown below:


Microsoft are aware of this bug and will be fixing it in Exchange 2016 CU3.

Until this bug is fixed, you need to create Frontend Transport receive connectors from shell as follows:

New-ReceiveConnector -Name "Application Receive Connector" -Bindings ("0.0.0.0:25") -RemoteIPRanges ("10.1.10.10") -MaxMessageSize 50MB –TransportRole FrontendTransport -Usage Custom –Server Bentley-EXCH


Monday, September 12, 2016

Deploying Exchange 2016 into an Exchange 2013 Organisation with MAPI over HTTPS Enabled

This issue may be encountered when migrating to Exchange 2016 from Exchange 2013 when MAPI over HTTPS is enabled.  The default Exchange 2013 MAPI over HTTPS authentication settings set IIS and Internal Authentication methods as Negotiate and External as null.  This is shown below:


The Default Exchange 2016 MAPI over HTTPS authentication settings are configured as "Ntlm, OAuth and Negotiate"


Proxying MAPI over HTTPS connections between Exchange 2016 and Exchange 2013 requires NTLM be enabled.  The default Exchange 2013 MAPI over HTTPS authentication settings will cause Outlook connectivity issues when both Exchange 2016 and Exchange 2013 are in the same Active Directory site.

The error which is generated by the Exchange Remote Connectivity Analyzer in this configuration is as follows:
 
https://testconnectivity.microsoft.com/Images/Error.png
 
 
Testing the MAPI Mail Store endpoint on the Exchange server.
 
An error occurred while testing the Mail Store.
 
https://testconnectivity.microsoft.com/Images/Minus.gif
Additional Details
 
Elapsed Time: 1243 ms.
 
https://testconnectivity.microsoft.com/Images/Minus.gif
Test Steps
 
https://testconnectivity.microsoft.com/Images/Error.png
Attempting to log on to the Mailbox.
 
An error occurred while logging on to the Mailbox.
 
https://testconnectivity.microsoft.com/Images/Minus.gif
Additional Details
 
A protocol layer error occured. MapiHttpServiceCode: 1722
FailureLID: 56412
FailureInfo:

###### REQUEST [2016-08-28T13:10:48.4483314Z] ######

POST /mapi/emsmdb/?mailboxId=a9888e6b-81d6-4495-b4b0-bcda772e782f@avantgardetechnologies.com.au HTTP/1.1
Content-Type: application/octet-stream
User-Agent: MapiHttpClient
X-RequestId: 0d3ddde1-1147-4cbe-a50b-ee75d2d1319d:2
X-ClientInfo: dfba427f-ffa7-4003-981f-a676bced12eb:1
X-ClientApplication: MapiHttpClient/15.0.4420.1017
X-RequestType: Execute
Authorization: Negotiate [truncated]
Host: mail.avantgardetechnologies.com.au
Cookie: ClientId=PAVTTKRDEJLCYBAF9MA; MapiContext=MAPIAAAAAOms6aTto+TJjNSX3/zO/s/51OTc8cP72+rY4tPh2+ragKOSpJSilaWUoZWn7QEAAAAAAAA=; MapiSequence=0-WbZNDg==; X-BackEndCookie=a9888e6b-81d6-4495-b4b0-bcda772e782f=u56Lnp2ejJqBy5nGz8vMz8/SysyaxtLLysqd0p3Jz5vSyMzKzpqbzJ2ancicgYHNz87J0s/G0s3Iq87Mxc7Pxc7G
Content-Length: 172

--- REQUEST BODY [+0.128] ---
..[BODY SIZE: 172]

--- REQUEST SENT [+0.128] ---

###### RESPONSE [+0.416] ######

HTTP/1.1 200 OK
Transfer-Encoding: chunked
request-id: 7f93a99a-4a53-4866-a978-8de3671a1dd7
X-CalculatedBETarget: leeming-exch.at.local
X-ServerApplication: Exchange/15.00.1210.002
X-RequestId: 0d3ddde1-1147-4cbe-a50b-ee75d2d1319d:2
X-ClientInfo: dfba427f-ffa7-4003-981f-a676bced12eb:1
X-RequestType: Execute
X-PendingPeriod: 30000
X-ExpirationInfo: 900000
X-ResponseCode: 0
X-DiagInfo: LEEMING-EXCH
X-BEServer: LEEMING-EXCH
Cache-Control: private
Content-Type: application/octet-stream
Set-Cookie: MapiSequence=1-S1NbMA==; path=/mapi/emsmdb; secure; HttpOnly,MapiContext=MAPIAAAAAOms6aTto+TJjNSX3/zO/s/51OTc8cP72+rY4tPh2+ragKOSpJSilaWUoZWn7QEAAAAAAAA=; path=/mapi/emsmdb; secure; HttpOnly,X-BackEndCookie=a9888e6b-81d6-4495-b4b0-bcda772e782f=u56Lnp2ejJqBy5nGz8vMz8/SysyaxtLLysqd0p3Jz5vSyMzKzpqbzJ2ancicgYHNz87J0s/G0s3Iq87Mxc7Pxc7G; expires=Tue, 27-Sep-2016 13:10:19 GMT; path=/mapi; secure; HttpOnly
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
Persistent-Auth: true
X-Powered-By: ASP.NET
X-FEServer: LEEMING-EXCH
Date: Sun, 28 Aug 2016 13:10:19 GMT

--- RESPONSE BODY [+0.416] ---
..[BODY SIZE: 4195]
PROCESSING [@2016-08-28T13:10:48.8643314Z]
DONE [+00:00:00]
X-StartTime: Sun, 28 Aug 2016 13:10:19 GMT
X-ElapsedTime: 16

..[DATA SIZE: 4112]

--- RESPONSE DONE [+0.418] ---

###### REMOTE-EXCEPTION-INFO ######

Microsoft.Exchange.Rpc.RpcException: Connection must be re-established ---> Microsoft.Exchange.RpcClientAccess.ServerUnavailableException: Connection must be re-established ---> Microsoft.Exchange.RpcClientAccess.SessionDeadException: The primary owner logon has failed. Dropping a connection. ---> Microsoft.Exchange.Data.Storage.TooManyObjectsOpenedException: Cannot open mailbox /o=AT/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Clint Boessenaa7. ---> Microsoft.Mapi.MapiExceptionSessionLimit: MapiExceptionSessionLimit: Unable to open message store. (hr=0x80040112, ec=1246) Diagnostic context: Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=502] Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=256][latency=0] Lid: 52176 ClientVersion: 15.0.1210.3 Lid: 50032 ServerVersion: 15.0.1210.6003 Lid: 23226 --- ROP Parse Start --- Lid: 27962 ROP: ropLogon [254] Lid: 17082 ROP Error: 0x4DE Lid: 26937 Lid: 21921 StoreEc: 0x4DE Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 ---- Remote Context Beg ---- Lid: 47536 Lid: 57936 dwParam: 0x20 Msg: MoMT Lid: 33360 dwParam: 0x21 Lid: 57384 StoreEc: 0x4DE Lid: 56872 dwParam: 0xFE Lid: 42712 StoreEc: 0x4DE Lid: 10786 dwParam: 0x0 Msg: 15.00.1210.000:Leeming-EXCH Lid: 1750 ---- Remote Context End ---- Lid: 26849 Lid: 21817 ROP Failure: 0x4DE Lid: 26297 Lid: 16585 StoreEc: 0x4DE Lid: 32441 Lid: 1706 StoreEc: 0x4DE Lid: 24761 Lid: 20665 StoreEc: 0x4DE Lid: 25785 Lid: 29881 StoreEc: 0x4DE
at Microsoft.Mapi.MapiExceptionHelper.InternalThrowIfErrorOrWarning(String message, Int32 hresult, Boolean allowWarnings, Int32 ec, DiagnosticContext diagCtx, Exception innerException)
at Microsoft.Mapi.ExRpcConnection.OpenMsgStore(OpenStoreFlag storeFlags, String mailboxDn, Guid mailboxGuid, Guid mdbGuid, String& correctServerDn, ClientIdentityInfo clientIdentityAs, String userDnAs, Boolean unifiedLogon, String applicationId, Byte[] tenantHint, CultureInfo cultureInfo)
at Microsoft.Mapi.MapiStore.OpenMapiStore(String serverDn, String userDn, String mailboxDn, Guid guidMailbox, Guid guidMdb, String userName, String domainName, String password, String httpProxyServerName, ConnectFlag connectFlags, OpenStoreFlag storeFlags, CultureInfo cultureInfo, Boolean wantRedirect, String& correctServerDN, ClientIdentityInfo clientIdentity, Boolean unifiedLogon, String applicationId, Client xropClient, Boolean wantWebServices, Byte[] clientSessionInfo, TimeSpan connectionTimeout, TimeSpan callTimeout, Byte[] tenantHint)
at Microsoft.Mapi.MapiStore.OpenMailbox(String serverDn, String userDn, Guid guidMailbox, Guid guidMdb, String userName, String domainName, String password, ConnectFlag connectFlags, OpenStoreFlag storeFlags, CultureInfo cultureInfo, ClientIdentityInfo clientIdentity, String applicationId, Byte[] tenantPartitionHint, Boolean unifiedLogon)
at Microsoft.Exchange.Data.Storage.MailboxSession.ForceOpen(MapiStore linkedStore, Boolean unifiedSession)
--- End of inner exception stack trace ---
at Microsoft.Exchange.Data.Storage.MailboxSession.ForceOpen(MapiStore linkedStore, Boolean unifiedSession)
at Microsoft.Exchange.Data.Storage.MailboxSession.Initialize(MapiStore linkedStore, LogonType logonType, IExchangePrincipal owner, DelegateLogonUser delegateUser, Object identity, OpenMailboxSessionFlags flags, GenericIdentity auxiliaryIdentity, Boolean unifiedSession)
at Microsoft.Exchange.Data.Storage.MailboxSession.<>c__DisplayClass1c.b__1a(MailboxSession mailboxSession)
at Microsoft.Exchange.Data.Storage.MailboxSession.InternalCreateMailboxSession(LogonType logonType, IExchangePrincipal owner, DelegateLogonUser delegatedUser, CultureInfo cultureInfo, String clientInfoString, IBudget budget, Action`1 initializeMailboxSession, InitializeMailboxSessionFailure initializeMailboxSessio
HTTP Response Headers:
Transfer-Encoding: chunked
request-id: 7f93a99a-4a53-4866-a978-8de3671a1dd7
X-CalculatedBETarget: leeming-exch.at.local
X-ServerApplication: Exchange/15.00.1210.002
X-RequestId: 0d3ddde1-1147-4cbe-a50b-ee75d2d1319d:2
X-ClientInfo: dfba427f-ffa7-4003-981f-a676bced12eb:1
X-RequestType: Execute
X-PendingPeriod: 30000
X-ExpirationInfo: 900000
X-ResponseCode: 0
X-DiagInfo: LEEMING-EXCH
X-BEServer: LEEMING-EXCH
Cache-Control: private
Content-Type: application/octet-stream
Set-Cookie: MapiSequence=1-S1NbMA==; path=/mapi/emsmdb; secure; HttpOnly,MapiContext=MAPIAAAAAOms6aTto+TJjNSX3/zO/s/51OTc8cP72+rY4tPh2+ragKOSpJSilaWUoZWn7QEAAAAAAAA=; path=/mapi/emsmdb; secure; HttpOnly,X-BackEndCookie=a9888e6b-81d6-4495-b4b0-bcda772e782f=u56Lnp2ejJqBy5nGz8vMz8/SysyaxtLLysqd0p3Jz5vSyMzKzpqbzJ2ancicgYHNz87J0s/G0s3Iq87Mxc7Pxc7G; expires=Tue, 27-Sep-2016 13:10:19 GMT; path=/mapi; secure; HttpOnly
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
Persistent-Auth: true
X-Powered-By: ASP.NET
X-FEServer: LEEMING-EXCH
Date: Sun, 28 Aug 2016 13:10:19 GMT
ServiceCode: 1722 Unavailable
Elapsed Time: 1243 ms.

To ensure all servers are configured correctly to proxy connections between Exchange 2013 and Exchange 2016, run the following PowerShell command:

Get-MapiVirtualDirectory | Set-MAPIVirtualDirectory -IISAuthenticationMethods Ntlm, OAuth, Negotiate


Hope this post has been helpful.

If you need IT Support in Perth, contact Avantgarde Technologies today.
 

Saturday, August 27, 2016

Certificate Warnings when upgrading to Exchange 2016

Because Exchange Server runs most of its configuration at an "Organisation Level" adding new Exchange Servers to an existing Exchange Environment can be a difficult challenge to ensure users get a seamless experience.  When adding new Exchange Servers to an organisation (such as Exchange 2016) in an existing Exchange 2013 organisation, the new Exchange 2016 server will immediately start advertising its SCP Autodiscover record and other internalURLs such as the MapiVirtualDirectory.

Whilst this does not cause direct issues to Exchange Resources, it will present certificate warnings on Outlook clients as the default Self Signed certificate will not be trusted on the Outlook clients.

Outlook Clients (if they are in the same Active Directory site) as the Autodiscover Site Scope will immediately start picking up the new Exchange server and communicating with it - hence generating certificate warnings such as the one below.

 
As an Exchange Administrator, your first task after building the new server is to immediately install a valid trusted certificate on your new Exchange server and update the Autodiscover SCP record on the new ClientAccessService with the Set-ClientAccessService cmdlet.  It is then very important to update all other URLs such as the MapiVirtualDirectory, Outlook Anywhere etc.

Changing the values for your new Exchange 2013/2016 servers however will not stop the certificate warnings from being displayed to users right away however.  Even though you update your Records, Outlook clients will continue receiving the old records for some time as shown in the screenshot below.


This occurs as when the Exchange 2016 server is first built, your Exchange 2013 servers will cache in the IIS AppPool these original records.  Your Exchange 2013 servers will continue to return via Autodiscover the record of the Exchange 2016 FQDN that does not match the name on the digital certificate.

To force your Exchange 2013 servers to start forcing the correct name immediately, an iisreset is required on all Exchange 2013 servers in the same Active Directory site as the new Exchange 2016 server.  This will cause a slight disruption for users.

See the issue?
  • As soon as your new Exchange 2016 server is installed, users will begin getting certificate warnings.
  • To quickly update the certificate and names of the Exchange Web Services, the iisreset on the Exchange 2013 servers will cause a slight outage.
Make sure you plan for this in your Exchange 2016 rollout.  Let users know in advance to ignore the certificate warning which will be displayed after the first Exchange 2016 server is built.  This will reduce the load on your companies service desk.

Wednesday, August 10, 2016

The Danger of the Local Administrator Account

The local administrator account resides on every Windows Server and is usually in an enabled state.  This account is a major security vulnerability and is commonly prone to hacking attempts.

Security flaws with this account include:
  • This account cannot be locked out and does not adhere to local or domain account lockout password policies.  This allows brute force attacks to be conducted against the account.
  • The local administrator account is a well known SID, it always begins with S-1-5- and end with -500.  There are also tools allowing you to login with a SID rather then an account name so an attacker could launch a brute force without knowing the account!

Quote from Microsoft https://technet.microsoft.com/en-us/library/jj852165.aspx"

"The built-in Administrator account cannot be locked out no matter how many failed logons it accrues, which makes it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum."

If security if your top concern, my recommendation is to disable this account and always create a new Administrator account regardless if it is the default domain Administrator account or default local Administrator account.

Need IT Support in Perth, give me a call now on 08 9468 7575

Thursday, July 21, 2016

Error downloading unsupported File Types with IIS

A customer of mine was complained that when users attempted to download unknown file types, they received a "404 - File or directory not found" error message.

The file type my user was attempting to download was a ".indd" file.


This error is caused when the filetype is not a supported "MIME" an IIS Web Server.

In the event you want to add a new unknown file type under the IIS Website, click MIME Types.


Add the unknown file extension users are attempting to download.


After adding the mime, do an "iisreset".

Users will now be able to download the unknown file type.

Wednesday, July 20, 2016

DFSR Event ID 6404 - The Replicated Folder has an Invalid Local Path

I was attempting to add a new DFSR node to an existing DFSR Replication Group consisting of 17 file servers.  When adding the server the following error was experienced.

DFS Replication cannot replicate the replicated folder REPLICATEDFOLDER because the local path E:\replicationgroup is not the fully qualified path name of an existing, accessible local folder. This replicated folder is not replicating to or from this server. Event ID: 6404


This particular error is generally experienced when people attempt a non NTFS volume such as ReFS to a DFSR replication group as documented on the following forum.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/8860b354-3bf2-43ed-9acf-07fa43931046/dfsr-replication-cant-be-used-on-a-refs-volume?forum=winserver8gen

 In my case, I experienced this error with DFSR setup on NTFS volume on a new branch server.

The customer moved the DFSR node from one office, to another office.  The C:\ "SYSTEM" volume was formatted and reloaded with a fresh copy of 2012 R2 with latest patches, however the E:\ "DATA" volume was not formatted.  As a result it has its legacy DFSR Database, Staging data etc.

To clean up the staging data I created a new directory in C:\ called "empty":

C:\Empty

I then ran the following commands after stopping the DFSR Replication service on the spoke server:

Robocopy "C:\Empty" "E:\System Volume Information\DFSR" /MIR

Followed by

rmdir "E:\System Volume Information\DFSR"

Starting the DFSR replication service resulted in the error above.

After playing around a bit more, I found that in addition to flushing all data in System Volume Information\DFSR you must also remove the DfsrPrivate link which points to the System Volume Information\DFSR sub directory for DfsrPrivate data.


After doing this, starting the DFS Replication service kicks of its normal DFSR Initial Sync shown by a state of 2:

Wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,state


State Values (Uninitialized, Initialized, Initial Sync, Auto Recovery, Normal, In Error), ValueMap (0, 1, 2, 3, 4, 5)}

Need help with DFSR In Perth?  Click for IT Support.

Tuesday, July 19, 2016

DFSR Backlog Count Not Reducing - Server 2012 R2

Microsoft recently released an update which causes DFSRS.exe CPU usage to hit 100%.

https://support.microsoft.com/en-us/kb/3156418

I wrote about this problem on the following blog post:

http://clintboessen.blogspot.com.au/2016/07/dfsr-service-100-cpu-usage.html

Since installing this update and removing this update, one of our spoke servers failed to replicate back to the primary hub server.  All data from the spoke server replicated correctly to the hub, however data from the hub was not propagating down to the spoke.

The backlog count continued to increase.
 


DFSR Hotfix https://support.microsoft.com/en-us/kb/2996883 was not installed on the affected hub server.

We knew there was no issue with our hub server as this was replicating successfully to 16 other DFSR spoke servers.

On the affected spoke server, I worked with the Directory Services team from Microsoft who made the following changes to the Network Interface.


C:\Windows\system32>netsh int tcp set global chimney=disabled
Ok.


C:\Windows\system32>netsh int tcp set global rss=disabled
Ok.


C:\Windows\system32>netsh int ip set global taskoffload=disabled
Ok.


C:\Windows\system32>netsh int tcp set global autotuninglevel=disabled
Ok.


C:\Windows\system32>netsh int tcp set global ecncapability=disabled
Ok.


C:\Windows\system32>netsh int tcp set global timestamps=disabled
Ok.


C:\Windows\system32>netsh advf set allp state off
Ok.


Microsoft then disabled the following Offload features on the HP Network Interface card on the spoke server:
  • IPv4 Large Send Offload
  • Large Send Offload V2 (IPv4)
  • Large Send Offload V2 (IPv6)
  • TCP Connection Offload (IPv4)
  • TCP Connection Offload (IPv6)
  • TCP/UDP Checksum Offload (IPv4)
  • TCP/UDP Checksum Offload (IPv6)
 
After disabling these components of the network interface card and restarting the DFS Replication service, the backlog count from the hub server to the spoke server slowly started decreasing.
 
TCP offload engine is a function used in network interface cards (NIC) to offload processing of the entire TCP/IP stack to the network controller. By moving some or all of the processing to dedicated hardware, a TCP offload engine frees the system's main CPU for other tasks

Sunday, July 10, 2016

DFSR Service 100% CPU Usage

I had an enterprise DFSR customer of mine with 17 File Server nodes complaining that CPU utilisation was at 100% on numerous DFSR nodes in the cluster.


In addition to the DFSR.exe process maxing out CPU on the file server, the following error was being generated on a regular basis:

Log Name:      Application
Source:        ESENT
Date:          7/07/2016 2:33:18 PM
Event ID:      623
Task Category: Transaction Manager
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SERVER.DOMAIN.LOCAL
Description:
DFSRs (1696)
\\.\E:\System Volume Information\DFSR\database_5AAC_EEEA_ACEE_C01D\dfsr.db: The version store for this instance (0) has reached its maximum size of 127Mb. It is likely that a long-running transaction is preventing cleanup of the version store and causing it to build up in size. Updates will be rejected until the long-running transaction has been completely committed or rolled back.
Possible long-running transaction:
 SessionId: 0x00000032FFE94EC0
 Session-context: 0x00000000
 Session-context ThreadId: 0x00000000000012BC
 Cleanup: 0
 Session-trace:
32997@2:32:18 PM


 
After speaking with the Directory Services team at Microsoft, this was due to a bug with KB3156418.  This was documented on the knowledge base website:
 
 
Symptoms
If you installed update rollup 3156418 on Windows Server 2012 R2, the DFSRS.exe process may consume a high percentage CPU processing power (up to 100 percent). This may cause the DFSR service to become unresponsive to the point at which the service cannot be stopped. You must hard-boot affected computers to restart them.

Workaround

To work around this problem, uninstall update rollup 3156418.

Status

Microsoft is aware of this problem and is working on a solution.

Make sure you do not install KB3156418 on any DFSR nodes until this issue has been fixed by Microsoft.
 

Wednesday, July 6, 2016

Bug with Windows 7 and Access Based Enumeration

I encountered an interesting bug with Windows 7 workstations with Access Based Enumeration enabled on a SMB Share and DFS Namespace running on Windows Server 2012 R2.

When a user tries to create a file or folder under a location which they have "Full Modify Rights" in Windows Explorer they receive the following error:

Drive Mapping refers to a location that is unavailable. It could be a hard drive on this computer, or on a network. Check to make sure that the disk is properly inserted, or that you are connected to the Internet on your network, and then try again. If it still cannot be located, the information might have been moved to a different location.


This issue occurs under the following circumstances:
  • Access Based Enumeration is enabled on a Network Share or DFS Namespace
  • If a Mapped Network Drive is created to the Share
  • The user is connecting from a Windows 7 workstation.

The Windows 7 client works under the following circumstances:
  • If the user creates a file from an application such as Microsoft Word (not Windows Explorer) using a mapped network drive to the folder share, it works corrctly.
  • If the user opens the UNC Path of the share \\server\share\folder, not via the mapped network drive it works correctly.
Note: If the user connects from 2008 R2, Windows 8.1 or Windows 10 it connects without issues.

When setting up Access Based Enumeration, the root folder should have:
  • List Folder / Read Data
  • Applies to "This Folder Only"
This ensures that users have the rights to list all folders at the base level folder for Access Based Enumeration, but requires additional rights to all sub folders hence the folders "hidden" as expected.

The root level permissions are shown below.  All sub folders are provided with full modify permissions for the respective security groups.

This works with 2008 R2, Windows 8.1 and Windows 10.

 
With Windows 7 clients they need additional permissions granted at the root level folder including:
  • Transverse folder / execute file
  • List folder / read data
  • Read Attributes
  • Read extended attributes
  • Read permissions
 
These extra permissions at the root level folder are only required if:
  • You run Access Based Enumeration
  • You have Windows 7 Clients on the network

Wednesday, June 29, 2016

IMAP4 Frontend with Exchange 2013

A customer of Avantgarde Technologies was having issues with IMAP4 on Exchange 2013.  In Exchange 2013 the IMAP Role has changed and how has a "front end" and "backend role".  This is shown by two services below.


The IMAP4 backend role listens on 127.0.0.1:143

If we telnet 127.0.0.1:143or "localhost" we hit the IMAP backend service.


If we telnet the server on any other IP address on TCP143 we hit the IMAP front end service.

This is what is confusing.  By default the IMAP4 frontend proxy server component is disabled even if the service is started.

If you telnet the server on its local IP address as shown below.


You will simply get a blank Telnet screen which will automatically close the session seconds after.


This happens as the ImapProxy frontend is disabled by default on the Server Component State of the server.


To enable it, use the following command.

Set-ServerComponentState -Identity Servername -State Active -Requester HealthAPI -Component ImapProxy

Need IT Support with Microsoft Exchange in Perth?  Click Here.

Tuesday, June 21, 2016

Modern Public Folders in Multi-Tenant Environments

Modern Public Folders is a new feature introduced in Exchange 2013 and also available in Exchange 2016 to allow companies to leverage Database Availability Groups and utilise log shipping as opposed to SMTP for replication providing numerous advantages which we will not focus on in this article.

If you new to Modern Public Folders, here is a good article to get you started:

http://www.msexchange.org/articles-tutorials/exchange-server-2013/planning-architecture/exchange-2013-preview-public-folders-part1.html

In this article, we will focus on Modern Public Folders in a multi-tenant environment.  We will be going through how to achieve multi-tenancy with Microsoft Exchange 2013 / 2016.

It is important to note, there are numerous methods for setting up Public Folder in a multi tenant environment.

In the example below we have:
  • One root Public Folder per tenant/company
  • One Public Folder Mailbox per tenant/company
  • One security group to represent all users from each tenant/company
  • Access based enumeration to each tenant/company can only see their root level Public Folder.
With Exchange 2013 and Exchange 2016, the first Public Folder mailbox created is always deployed as the Master Hierarchy Mailbox.  This mailbox is the only Public Folder mailbox with a writeable copy of the Public Folder hierarchy.  All additional Public Folder mailboxes created contain a read-only copy of the hierarchy.

When we are talking about Hierarchy, we are not talking about Public Folder content, only the folder structure which makes up the Public Folders.

First thing we need to create is a master Public Folder Hierarchy mailbox.  In a multi-tenant environment I generally recommend no content be placed in the master Public Folder Hierarchy mailbox and it only be used to maintain the writeable copy of the Public Folder Hierarchy.

As the first Public Folder mailbox created is always the Master Hierarchy, simply use the New-Mailbox command to create the mailbox.  I always recommend clearly naming this mailbox so it is easily identifiable as the Public Folder Mailbox Hierarchy mailbox.  This was done by giving it the name of "MasterHierarchy".


Next create a Public Folder mailbox for each tenant/company.  The intent here is all content for each company will be stored in their respective public folder mailbox.  In this example we will be using my company Avantgarde Technologies as an example tenant.  I'm using the naming convention CompanyPF for each respective Public Folder mailbox.


Next create a new Public Folder at the root "\" of the Hierarchy.  Make sure you specify the Public Folder mailbox you want to store the Public Folder in or by default Exchange will automatically pick any Public Folder mailbox which could be the Master Hierarchy mailbox or another tenants mailbox.

The name of the Public Folder specified below is the name the tenant will see in Outlook.


By default, all root public folders can be seen by all tenants.  To ensure no tenants can see the "Avantgarde Technologies" root level Public Folder, remove the Default user Access Rights as shown in the screenshot below.  This will ensure no one can see this Public Folder.


Lastly, ensure you have a Security Group containing all users from the tenant/company. Grant the group access to the root level Public Folder - I recommend Owner or PublishingEditor rights or refer to the following TechNet article about other Public Folder permissions you can grant here.


Only users of the "Avantgarde Users" security group will be able to see the root Public Folder Avantgarde Technologies and all other Tenants in the environment will be hidden to the Avantgarde Technologies employees.


To add additional tenants to the environment, repeat the process documented above.  Make sure you ensure that:
  • All root level public folders have the default user permissions removed straight away to protect privacy of each tenant on your Exchange environment.
  • When creating the root level public folders in PowerShell you manually specify the correct Public Folder mailbox or Exchange will pick one at random.
  • Consider using provisioning scripts to remove user error and protect yourself against privacy breaches.
All sub-folders created in Outlook will automatically append to the parents Public Folder mailbox.

One last thing I want to touch on is the "-DefaultPublicFolderMailbox" of the Set-Mailbox command.  Many people when they initially go about setting up Public Folders for multi-tenant Exchange they think about creating a public folder mailbox for each tenant then using "-DefaultPublicFolderMailbox" for all user mailboxes of each tenant.  Before writing this article I googled around to see if there was already an article similar, and saw people were attempting this incorrect method of deployment.  The reason this approach will not work is as mentioned earlier, all Public Folder Mailboxes have a "read only" copy of the entire Public Folder Hierarchy (meaning all Public Folders in the Exchange Organisation).  This means "yes they do have the Public Folder structure of other tenants/companies in the environment".  We want to ensure tenants only see public folders related to their company by locking down permissions to meet privacy reasons.

I hope this article has been informative for you and I would like to thankyou for reading.

Click here for IT Support in Perth with Microsoft Exchange

Friday, June 17, 2016

Setting Delivery Restrictions and Exchange Administration Center

Delivery Restrictions is a feature of Exchange Server which has been around since Exchange 2000 and allows companies to easily limit who can send to a distribution list or mailbox.  A very common use of Delivery Restrictions is to limit who can send to the "All Users" or "All Staff" distribution group.

In previous releases of Exchange such as 2010, 2007 and even 2003 - delivery restrictions were very easy to configure via the Graphic User Interface (GUI).

In later revisions of Exchange, Delivery Restrictions have been left out of the GUI and now must be configured by PowerShell.

This can be easily configured by using the "AcceptMessageOnlyFrom" attribute on DistributionGroups and Mailboxes for which you want to configure Delivery Restrictions.  The "AcceptMessagesOnlyFromDLMembers" is when you want to limit the group/mailbox to a Group of users who are allowed to send.


To set this, simple:

Set-DistributionGroup "Avantgarde Users" -AcceptMessageOnlyFrom "Clint Boessen"

However what if you want to configure multiple users or groups who need delivery restrictions on a mailbox or distribution group?  The -AcceptMessageOnlyFrom attribute does not allow you to comma separate values.

This is where it becomes more complicated...

Here is the syntax to add multiple groups or users to Delivery Restrictions in PowerShell:

Set-DistributionGroup -Identity "All Staff" -AcceptMessagesOnlyFromDLMembers "All Managers"

Set-DistributionGroup "All Staff" -AcceptMessagesOnlyFromDLMembers((Get-DistributionGroup "All Staff").AcceptMessagesOnlyFromDLMembers + "Executive Assistant")

Set-DistributionGroup "All Staff" -AcceptMessagesOnlyFromDLMembers((Get-DistributionGroup "All Staff").AcceptMessagesOnlyFromDLMembers + "Executive Group")


I hope this post has been helpful!

Need IT Services in Perth from Subject Matter Experts?

Exchange 2016 CU2 - Automatically Move Exchange Databases back to Preferred Server

In Exchange 2016 CU2, Microsoft has released a new feature which has been a request of mine since the release of Exchange Database Availability Groups (DAGs) in Exchange 2010.  I have built many Exchange 2010/2013 and 2016 clustered environments for customers around Perth over the years however one problem I always see is customers do not rebalance databases after Windows Updates.

Many customers (even after trained) do not put DAG nodes into maintenance mode and simply install updates on a node and reboot causing a database failover to occur.  They then do the remaining servers in the cluster usually ending up with all databases residing on a single server.

In Exchange 2016 CU2 there is a new shiny feature which "automatically fails back" the database to the preferred server based on Activation Preference.  This is known as "PreferenceMoveFrequency".

After all your Exchange 2016 servers (or more technically the Primary Active Manager) have been upgraded to Exchange 2016 CU2, you will have a new DAG property called PreferenceMoveFrequency.

What this switch does is define a frequency (measured in time) when the Microsoft Exchange Replication service will rebalance the database copies by performing a lossless switchover that activates the copy with an ActivationPreference of 1.

How cool is that... automatic failback to preferred members.

Now when I build a new Exchange cluster for a customer, after I leave and close out the project I can be sure that the databases will automatically fail back to the preferred server after the customer installs Windows Updates on cluster nodes.  This is important as it keeps the load across the cluster balanced.

To set this feature, simply use the following PowerShell command:

Set-DatabaseAvailabilityGroup -Identity DAG01 -PreferenceMoveFrequency ([TimeSpan]::Zero)

Need specialised Exchange consulting in Perth?  Contact Avantgarde IT Services on 08 9468 7575

Sunday, June 12, 2016

Reduce your IT Support costs by purchasing quality hardware upfront

During my career in the IT Industry, I see many small business entities purchase cheap consumer grade hardware from a local computer store in order to reduce IT costs.  This is bad practice and almost always leads to significantly higher IT Support costs in the long term.

For more information, please see my article "The Importance of Quality Hardware to reduce IT Support Costs"

http://www.articlesbase.com/computers-articles/the-importance-of-quality-hardware-to-reduce-it-support-costs-7457694.html

Reduce your IT Support Costs in Perth by talking to us now.

Tuesday, June 7, 2016

.NET Framework 4.6.1 and Exchange 2013 / 2016

Currently with Exchange 2013 CU12 and Exchange 2016 CU1, it is not supported to install .NET Framework 4.6.1 as it causes issues databases unexpectedly dismount or failover to alternative servers within a DAG cluster.  This issue is documented on the following KB article:

https://support.microsoft.com/en-us/kb/3095369

To ensure .NET Framework 4.6.1 does not install on your Exchange Servers, make sure you put the following registry key in place on your Exchange Servers:
  1. Back up the registry.
  2. Start Registry Editor. To do this, click Start, type regedit in the Start Search box, and then press Enter.
  3. Locate and click the following subkey:

    HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP
  4. After you select this subkey, point to New on the Edit menu, and then click Key.
  5. Type WU, and then press Enter.
  6. Right-click WU, point to New, and then click DWORD Value.
  7. Type BlockNetFramework461, and then press Enter.
  8. Right-click BlockNetFramework461, and then click Modify.
  9. In the Value data box, type 1, and then click OK.
  10. On the File menu, click Exit to exit Registry Editor.
What if I have already installed .NET Framework 4.6.1 on my Exchange Servers?  If so use the following procedure:
  1. If the server has already automatically updated to 4.6.1 and has not rebooted yet, do so now to allow the installation to complete
  2. Stop all running services related to Exchange.  You can run the following cmdlet from Exchange Management Shell to accomplish this:  (Test-ServiceHealth).ServicesRunning | %{Stop-Service $_ -Force}
  3. Go to add/remove programs, select view installed updates, and find the entry for KB3102467.  Uninstall the update.  Reboot when prompted.
  4. Check the version of the .NET Framework and verify that it is showing 4.5.2.  If it shows a version prior to 4.5.2 go to windows update, check for updates, and install .NET 4.5.2 via the KB2934520 update.  Do NOT select 4.6.1/KB3102467.  Reboot when prompted.  If it shows 4.5.2 proceed to step 5.
  5. Stop services using the command from step 2.  Run a repair of .NET 4.5.2 by downloading the offline installer, running setup, and choosing the repair option.  Reboot when setup is complete.
  6. Apply the February security updates for .NET 4.5.2 by going to Windows update, checking for updates, and installing KB3122654 and KB3127226.  Do NOT select KB3102467.  Reboot after installation.
  7. After reboot verify that the .NET Framework version is 4.5.2 and that security updates KB3122654 and KB3127226 are installed.
  8. Follow the steps here to block future automatic installations of .NET 4.6.1.
Need IT Support Perth?  Contact Avantgarde Technologies on 08 9468 7575

Monday, May 2, 2016

Windows 7 Computers Rebooting During Day for Updates

A customer was having an issue where Windows 7 computers randomly rebooted during the day for Windows Updates without providing a prompt for users the option to postpone updates.  This was resulting in frustrated users with computers rebooting in the middle of sending important emails, word processing tasks etc.

We checked Group Policy Windows Update settings, all was configured correctly however computers still rebooted.

After troubleshooting further, we found that a deadline in WSUS was set to "Same day approval at 5:00AM".  This meant as a deadline was set at 5:00AM in the morning, as soon a computers received the update upon boot, they already missed the deadline and immediately installed without prompting users to postpone the reboot.


We removed the setting for same day approval and this resolved the problem.

Avantgarde Technologies, a leading IT Support Perth based company.

Wednesday, April 13, 2016

Windows 7 SP1 hanging on Checking for Updates

Trying to perform a simple task of installing Windows 7 x64 Enterprise with Service Pack 1 on some virtual machines in my lab to test a product.  Windows 7 SP1 comes with Internet Explorer 8 and is very out of date in most aspects for application testing.

After in building a few Windows 7 VM's from my ISO, all of them sat there hanging on "Checking for Updates" for hours.

Ugg... something I didn't have time for as I was trying to test something urgently for a customer.

After installing the latest Windows Update client from https://www.microsoft.com/en-us/download/details.aspx?id=49540 on each freshly built Windows 7 workstation, they then detected updates in 4 minutes and I was able to start patching.

Wednesday, March 16, 2016

Microsoft Word Performance Issues - KB3114717

A customer contacted me mid-February complaining of significant performance issues with Microsoft Word 2013 SP1 (32bit).  When users copied and pasted text, scrolled up and down a document or changed formatting Microsoft Word continuously hung and entered a not responding state.  In addition users sometimes experienced up a 60 second delay when typing from when characters appeared on the screen.

We did significant troubleshooting on the issue including
  • Disabled Anti-Virus products
  • Full malware scan using multiple AV engines
  • Disabled all non Microsoft services and applications from System Startup
  • Disabled all Microsoft Word Add-ins
  • Disabled graphics acceleration in Microsoft Word
None of these troubleshooting steps resolved the issue.

After talking to Microsoft, it turns out that Microsoft released a bad Windows Update KB3114717.  This update was released on the 9th of February and caused numerous performance issues with Microsoft Office.  After removing this update from all workstations, it resolved the issue.

Tuesday, March 15, 2016

Searching RBL Agent Logs on Microsoft Exchange

In this blog post I will show you a quick way to search through large amounts of Real Time Blacklists logs on an Exchange Server.  This article assumes you have RBL Providers in place on an Exchange server which can be enabled as per the following article:

http://clintboessen.blogspot.com.au/2014/05/rbl-providers-and-exchange-2013.html

Once RBL listing is turned on, you will have a bunch of log files under the following directory (provided Exchange was installed to the default C:\ directory):

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\AgentLog


We want to track down which RBL provider blocked an email from a spammer with the from address of bqmppf@apremiertravel.com but we first need to identify what log file contains the entry.  To do this open a command prompt and navigate to the FrontEnd\AgentLogs directory.

Run the following command:

find /c "bqmppf@apremiertravel.com" *.log | find ":" | find /v ": 0"

After running this command we can see that it found one entry for bqmppf@apremiertravel.com in the file AGENTLOG20160313-1.LOG.


Open the log and search for the email in question.


We can see this email was blocked by zen.spamhaus.org RBL provider.


Hope this post was helpful. 

Wednesday, March 9, 2016

Remove Run menu from Start Menu - Policy Bug

Today I stumbled across a bug with Windows 8.1 / 2012 R2 with the Group Policy setting:

User Configuration ->Policies -> Administrative Templates -> Start Menu and Taskbar-> Remove Run menu from Start Menu

I had this policy applied to a Remote Desktop Session Host through Loopback in a user session lockdown policy.

When this policy was applied, I could not access any network share on my 2012 R2 file servers and received the following error message:

Accessing the resource \\fileserver\share has been disallowed.


I could received the same error when attempting to access the file server shares through a DFS namespace.

After removing this policy setting from my RD Session Hosts, the issue was resolved.

Monday, February 15, 2016

Windows cannot move object because Access is denied

I came across an interesting error today when attempting to move a security group to a new location in Active Directory.

Windows cannot move object because Access is denied


This issue was caused by "Protect object from accidental deletion"


By default this feature is only enabled on organisational units however in this environment, some groups and user objects had this feature enabled as well.  I believe this was manually enabled by a sysadmin in the past.

Tuesday, January 26, 2016

Why my Domain Password Policy Not Applying?

Back in 2009 I published a very popular article "The Low-Down on Password Policies" which has been viewed by thousands of IT Professionals and referenced by application vendors in online documentation such as SysOp Tools Software.

http://clintboessen.blogspot.com.au/2009/12/low-down-on-password-policies.html

In this post we are going to talk about password policies further and cover off what appears to be a bug but is actually "by design".

My customer had a handful of domain controllers with a single 2008 R2 domain controller and three Server 2012 R2 domain controllers.  The PDC Emulator resides on Server 2008 R2.

The Server 2008 R2 domain controller was applying the password policy correctly however the 2012 R2 domain controllers were not (or so I thought).

Running an rsop.msc on the 2008 R2 domain controller (the PDC) shows the policy being applied from the Default Domain Policy.

 
 The 2012 R2 domain controllers the resultant set of policy displayed no policies being applied.


The same was experienced running an "gpresult /v" on the 2008 R2 or 2012 R2 domain controllers.

"gpresult /v" on 2008 R2:

 
"gpresult /v" on 2012 R2:
 
 
The account policies above are the domain Kerberos policy, not the password policy.
 
The password policy simply did not apply to the 2012 servers.  After further investigation in my test lab, I saw that only the domain controller running the PDC emulator displays the password policy when performing a Resultant Set of Policy.
 
This means every domain controller in a domain will not display the password policy from a resultant set of policy apart from the primary domain controller.
 
How do I check if the password policy is applying correctly on my domain controllers?
 
There are two commands which check the password policy:
  • net accounts (checks local password policies on a server)
  • net accounts /domain (checks the domain password policy on a server)
 
 
 
Domain Policy always wins over a local policy.
 
Computer Role: Backup means it is not a Primary Domain Controllers (PDC).
 
So in summary... if you see a password policy not applying to a domain controller when you check Group Policy, this is normal behaviour and is by design unless the server is the PDC emulator.