Single AD Site-Link: Don’t do it.

Dirk & Brad's Windows Blog

One of the frequent issues we see when supporting Small to Medium businesses (SMB) is replication issues caused by problems with physical Active Directory design. When I say “physical design” I don’t mean forests, tree roots, domains, child domains, etc. Those are elements of logical design. Physical design, in a nutshell, is how you configure the various elements in Active Directory Sites & Services. When these elements work harmoniously, Active Directory will reward you with fast & efficient replication. If mistakes are made, they’ll be compounded by the amount of replication traffic and at worst (typically in coordination with some other misconfiguration) can bring replication grinding to a halt. So let’s go over physical Active Directory design at a basic level.

The first rule of physical design is “You do not talk about Fight Club.” Wait a minute……wrong topic; my mistake. The first rule of physical design is to let…

View original post 1,052 more words

Creating a wildcard webserver certificate with your internal Microsoft CA

Robbie Roberts Blog OCS, Exchange & Technology

It is sometimes necessary to issue a wildcard certificate from your internal Microsoft CA, I had such a requirement this week and thought it would make a nice blog post.

The post assumes you have a Enterprise CA already deployed and a web server template deployed and available for enrolment.

First we need to create the certificate request that will be issued to your CA.

1. Logon to a Windows 2008 R2 or Windows 7 domain member

2. Open the certificates MMC snap-in






Now create the certificate request

3. Right click the Certificates folder which is found under the personal folder

4. Select All Tasks > Advanced Options > Create Custom Request


5. In the Certificate Enrolment Wizard Click Next


6. In the Certificate Enrollment Page select Custom Request > Proceed without enrolment Policy and then select Next


7. In the Custom Request Page select (No template) Legacy Key from…

View original post 379 more words

Exchange 2010 SP3 sets AllowCrossSiteRPCClientAccess back to false

Jason (Izzy) Sherry's Blog

If you have any scripts, like those used during the failover process, that use this cmdlet for Exchange 2010 you need to update them to set this value each time.

Just add “–AllowCrossSiteRPCClientAccess $True” to the cmdlet line when calling Set-DatabaseAvailabilityGroup, this assumes  you want to allow cross site RPC access without requiring your users to restart Outlook when their active database is moved to another AD Site.

Set-DatabaseAvailabilityGroup –AllowCrossSiteRPCClientAccess $True.

I’m pretty sure  I’ve seen this value reset back to $False with SP2 (RU unknown) also, so this “bug” might have existed before SP3. This switch was added, or really it started working, in SP2 RU3.

See this blog post for more details:

For general Exchange 2013 questions or to discuss non-support topics join the “Microsoft Exchange 2013” Facebook group I admin:

For community based support goto TechNet forums:

View original post

Samba config with Windows Registry Editor

Look at

When you would not use a smb.conf and edit under Windows


       Starting with Samba version 3.2.0, the capability to store Samba
       configuration in the registry is available. The configuration is stored
       in the registry key HKLM\Software\Samba\smbconf. There are two levels
       of registry configuration:

        1. Share definitions stored in registry are used. This is triggered by
           setting the global parameter registry shares to “yes” in smb.conf.

           The registry shares are loaded not at startup but on demand at
           runtime by smbd. Shares defined in smb.conf take priority over
           shares of the same name defined in registry.

        2. Global smb.conf options stored in registry are used. This can be
           activated in two different ways:

           Firstly, a registry only configuration is triggered by setting
           config backend = registry in the [global] section of smb.conf. This
           resets everything that has been read from config files to this
           point and reads the content of the global configuration section
           from the registry. This is the recommended method of using registry
           based configuration.

           Secondly, a mixed configuration can be activated by a special new
           meaning of the parameter include = registry in the [global] section
           of smb.conf. This reads the global options from registry with the
           same priorities as for an include of a text file. This may be
           especially useful in cases where an initial configuration is needed
           to access the registry.

           Activation of global registry options automatically activates
           registry shares. So in the registry only case, shares are loaded on
           demand only.

       Note: To make registry-based configurations foolproof at least to a
       certain extent, the use of lock directory and config backend inside the
       registry configuration has been disabled: Especially by changing the
       lock directory inside the registry configuration, one would create a
       broken setup where the daemons do not see the configuration they loaded
       once it is active.

       The registry configuration can be accessed with tools like regedit or
       net (rpc) registry in the key HKLM\Software\Samba\smbconf. More
       conveniently, the conf subcommand of the net(8) utility offers a
       dedicated interface to read and write the registry based configuration
       locally, i.e. directly accessing the database file, circumventing the