Archive by Author

Post Installation Script (Post_Install.bat) Template for Windows Server 2008 R2 Root CA

While implementing PKI at my current employer, I used the Microsoft Press books extensively to develop our implementation strategy.  While doing so, I noticed that some of the scripts in the book had errors in them, so I ended up revising them to correct the errors and implement PKI with the policies we felt worked best in our environment.

The Post Installation Script below is specifically for a Root CA in a three tier hierarchy.  With this policy, your Root CA certificate will last 20 years and you will only need to update your CRL once a year, allowing you to keep the Root CA offline all but a few minutes a year.  We did that in the CAPolicy.inf file as well, but this makes doubly sure that those settings were set.

Additionally, we are using this batch file to set publication points in Active Directory as well as on two web servers.  Those web servers will be listed on the Root CA Certificate, but you will need to copy the CRL’s and CRT’s there from %SystemRoot%\System32\CertSrv\CertEnroll.  As your Root CA should not be a member of the domain, you will also need to import the certificates into Active Directory.

Copy the text below into a file named Post_Install.bat and run it on your Root CA immediately after Active Directory Certificate Services role installation.


::Root CA Post Installation Script
::Declare Configuration NC
certutil -setreg CA\DSConfigDN CN=Configuration, DC=DOMAIN,DC=TLD

::Define CRL Publication Intervals
certutil -setreg CA\CRLPeriodUnits 52
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLOverlapUnits 2

::Apply the required CDP Extension URLs
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n10.ldap:///CN=%%7%%8,CN%%2,CN=CDP,CD=Public Key Services,CN=Services,%%6%%10\n2:http://WEBSERVER1/Certdata/%%3%%8%%9.crl\n2:http://WEBSERVER2/Certdata/%%3%%8%%9.crl"

::Apply the required AIA Extension URLs
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://WEBSERVER1/CertData/%%1_%%3^^4.crt\n2:http://WEBSERVER2/CertData/%%1_%%3^^4.crt"

::Enable all auditing events for the Root CA
certutil -setreg CA\AuditFilter 127

::Set Validity Period for Issued Certificates
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"

::Enable discrete signatures in subordinate CA certificates
Certutil -setreg CA\csp\DiscreteSignatureAlgorithm 1

::Restart Certificate Services
net stop certsvc & net start certsvc

Install Policy (CAPolicy.inf) Template for Windows Server 2008 R2 Root CA

While implementing PKI at my current employer, I used the Microsoft Press books extensively to develop our implementation strategy.  While doing so, I noticed that some of the scripts in the book had errors in them, so I ended up revising them to correct the errors and implement PKI with the policies we felt worked best in our environment.

The Install Policy below is specifically for a Root CA in a three tier hierarchy.  With this policy, your Root CA certificate will last 20 years and you will only need to update your CRL once a year, allowing you to keep the Root CA offline all but a few minutes a year.

Copy the text below into a file named “CAPolicy.inf” and place it in C:\Windows prior to adding the Active Directory Certificate Services role on your Root CA.


[Version - ROOT CAPolicy]
Signature="$Windows NT$"

[certserv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=20
RenewalValidityPeriod=years

CRLPeriod=weeks
CRLPeriodUnits=52
CRLOverlapPeriod=weeks
CRLOverlapUnits=2
CRLDeltaPeriodUnits=0
CRLDeltaPeriod=days

AlternativeSignatureAlgorithm=1

How to Install Root CA Certificates on Policy CA

Prior to installing the Policy CA certificate that is issued by the Root CA, you will need to install the Root CA Certificates on the Policy CA so that it knows it can trust the CA that issued its certificate.

To do this, copy the Root CA certs from “%SystemRoot%\System32\CertSrv\CertEnroll” on the Root CA to a directory on the Policy CA (I used c:\RootCA as an example below), and then run this script (modify paths & filenames) to add them to the local certificate store.


certutil -addstore -f Root "C:\RootCA\ROOTCA.crt"
certutil -addstore -f Root "C:\RootCA\ROOTCA.crl"

User with Exchange 2003 Mailbox Cannot Manage Membership of Exchange 2010 Distribution Group

Consider the following scenario:  You have added Exchange 2010 to your Exchange 2003 infrastructure and intend on running both simultaneously for a period of time.

You create a new Distribution Group in Exchange 2010, and use the Exchange Management Console/Shell to add multiple users as managers for the group, including one or more Exchange 2003-based users.  After doing so, the Exchange 2003 users cannot manage the membership of the distribution group through Outlook.

However, any Exchange 2010-based users can manage the membership of the group.

Root Cause
In Exchange 2003, you would specify a single manager for a Distribution Group by using Active Directory Users and Computers; specifically the Managed By tab in the properties of the group.

In Exchange 2010, you can set multiple managers for a Distribution Group by using the Exchange Management Console/Shell.  This is done by going to the properties of the specific Distribution Group, and then clicking on the Group Information tab.  The “Managed By” section will allow you to add as many members as you wish.

When a group is created in Exchange 2010 and multiple managers are specified, only one of those managers (the first one added), will appear on the “Managed By” tab if you look at the properties from within Active Directory Users & Computers on a computer with the Exchange System Manager installed.

Therefore, as far as Exchange 2003 is concerned, only one user actually has “manage” permissions for the Distribution Group.

Solution
If you only have one Exchange 2003 user that needs permissions to manage the Distribution Group, you can use Active Directory Users & Computers to set them as the manager of the group.

That action will not affect the other managers of the group specified in the Exchange 2010 Management Console as long as they are homed on an Exchange 2010 server.

If you have multiple Exchange 2003 users that need to manage the membership of a Distribution Group, you will have to migrate those users to Exchange 2010.

Additional Information
In addition, you will likely need to ensure that you follow the instructions in this blog from Microsoft:

http://blogs.technet.com/b/exchange/archive/2009/11/18/3408844.aspx

By default, users are prevented from managing the membership of a Distribution Group in Exchange 2010 even if they are specified under “Managed By:” on the Group Information tab.  The above blog outlines this behavior in Exchange 2010 and the steps/scripts necessary to remedy it.

How to Stop SPAM Text Messages with AT&T Wireless

Lately, I’ve been getting a lot of SPAM text messages on my phone and had some friends complianing about it as well.  Wanting it to stop, I went looking for a solution.

Turns out you can create a “text messaging” admin account on a special AT&T web site.  This allows you to set up a “block” list for people spamming you, as well as an “allow” list for people you want to be certain get through.

More importantly, it allows you get to get rid of the email address mapped to your phone.  Many AT&T subscribers probably aren’t even aware that by sending an email to YourMobileNumber@txt.att.net the email will be turned into a text and sent to their phone.

That’s how a lot of SPAM text messages originate.  A spammer simply sends out a slew of emails to EveryPhoneNumber@txt.att.net… since email is free it doesn’t cost them a dime, but it costs you a text message and a fair bit of annoyance.

After using their site to set up an alias, you can then turn on blocking so that messages sent to (in my case) YourMobileNumber@txt.att.net are automatically rejected, but messages sent to your alias are accepted.  That way, spam messages sent to every known phone number will be rejected (i.e. you’ll never see them), but the ones you actually need will go through just fine.  This will have absolutely no effect with your friends sending you text messages from their mobile phones.

You can also just block all messages sent to you as email (that option is on the first page of AT&T’s messaging administration web site), but working in IT I needed that capability for monitoring alerts and such.

To set up this ability on your phone, use the following site… you’ll need to register with AT&T:

http://mymessages.wireless.att.com/

Fighting for a SPAM free world : )

How to Modify the Default OU for New Distribution Groups in Exchange 2010

When creating a new distribution group with the Exchange Management Shell or Console in Exchange 2010, it will by default attempt to place the group in the Domain\Users (CN=Users,DC=domain,DC=com) folder.

While it is simple enough to specify the organizational unit (OU) while creating the distribution list, it is sometimes difficult for delegates to remember to specify the OU.

The solution is to use the Set-OrganizationConfig in order to change the default OU to whatever you want it to be.  Just launch the Exchange Management Console and run the following command:


Set-OrganizationConfig –DistributionGroupDefaultOU “[distinguishedName of OU]”

If you’re unfamiliar with how to retrieve the distinguishedName of the OU, just go to Active Directory Users & Computers and select View – Advanced Features.

Now, find the OU and right-click on it to select Properties.  There should be an Attribute Editor tab displayed which will list out all of the attributes for the OU, including the distinguishedName (you can double-click on it in order to copy/paste it in to your command).

If you would like to do the same thing for new mailboxes that are created, you can’t (at least as of SP1). The only way to enable similar funcationality for mailboxes is to use mailbox templates, which then require that you create all new mailboxes from the Exchange Management Shell instead of the console.

How to Turn Off Attachment Filtering on Exchange 2010 Edge Transport

We had an interesting issue recently where our Exchange 2010 Edge Transport server was erroneously stripping out .zip files.  The funny thing was that we really didn’t intend for it to be doing attachment filtering in the first place as we have a variety of other tools in place to take care of that.  It’s enabled by default though, and I wanted it off, so we needed to add an exception for our receive connector.

It’s not as straightforward as you would expect though to turn off attachment filtering on an Exchange 2010 Edge Transport server.

The first step is to see if there are any connectors on the attachment filter exception list presently.  To do so, run this command:


Get-AttachmentFilterListConfig

About the fifth line down you should see “ExceptionConnectors” which probably has nothing next to it.  Even if it does, it really doesn’t matter, we’re just checking so that we know the current state of affairs (always best to know your starting point so that you can check again at the end and make sure you were successful with what you think you did).

You can only turn off attachment filtering by referencing the GUID, so now we need to get the GUID of the relevant receive connector.  In our situation, the connector’s name was “Inbound from Internet,” so we run this command:


Get-ReceiveConnector "Inbound from Internet" | Format-List

This will give us all the properties of our Receive Connector, including the GUID, which will be listed about 10 lines up from the bottom.

Now that we have the GUID, we can run the command to add the receive connector to the list of exceptions for attachment filtering by running this:


Set-AttachmentFilterListConfig –ExceptionConnectors [GUID]

Replacing [GUID] with the GUID we retrieved in the previous step.

Finally, run Get-AttachmentFilterListConfig again and check the Exceptions line, you should now see your receive connector listed there.

ODBC Drivers Missing from Windows 7 64-Bit

If you go in to the Windows 7 Administrative Tools and double-click on the “Data Sources (ODBC)” icon just as you always have, and then attempt to add a new User DSN or System DSN, you will notice that there are almost no ODBC drivers to choose from.  This is especially confusing for end users who are simply trying to set up a connection to an Access or SQL database.

The secret is that most of those drivers are 32-bit, so, in order to access them you must right click on the “Data Sources (ODBC)” icon and choose “Run as Administrator” in order to see them.  Doing so allows the 64-bit Control Panel applet to display them.

Alternatively, you can simply launch c:\windows\sysWOW64\odbcad32.exe, which launches the 32-bit version of the “Data Sources (ODBC)” applet.

Bonus Tip:  With Windows 7, most organizations are no longer giving end users administrative rights to their workstations.  One consideration in regards to ODBC connections is that in order to create a System DSN, you must be an administrator of the local workstation.

Creating System DSN’s has been the defacto standard of most installation instructions that require DSNs for years, so you will likely need to modify any documentation.  User DSN’s work just as well as System DSN’s, except they must be set up individually for every user on a workstation.

Resolution for Unexplained Failure of MDT 2010 Inject Drivers Task

I was recently asked to troubleshoot an issue for our OS build team at work.  They had recently switched from Altiris 6.9 Deployment Server to Microsoft Deployment Toolkit 2010 Update 1 and were having a devil of a time with getting the driver injection to work with Windows 7… even under the simplest of circumstances.  Nothing made sense as to why it wasn’t working.

After going through the entire environment top to bottom, and watching the deployment process over and over again, I finally happened upon the solution.  It turned out to be one of those seemingly insignificant things that caused the whole process to fail.

It turns out the solution was actually quite simple, though difficult to find.  If c:\drivers exists in the captured .wim file (as it did for us, and this is generally a hidden folder so it may not be readily apparent that it is there), the Inject Drivers task during the Preinstall phase of the Task Sequence will not copy any new files to it, so the drivers never get copied.

Instead, it drops them in c:\windows.old\drivers (hidden of course), and doesn’t do anything with them.

Since it’s the windows installation and not the MDT scripts doing that, it’s not a logged action in the deployment logs making it incredibly difficult to troubleshoot.

A couple of other useful tips we discovered along the way.  First, it may be necessary to disable the requirment of signed drivers in Windows 7 to support all drivers you wish to inject.  You can use the local group policy in order to do this, but if you want to integrate it into your build process you can run these two commands:


bcdedit.exe -set loadoptions DDISABLE_INTEGRITY_CHECKS 

bcdedit.exe -set TESTSIGNING ON

Restart your computer for the changes to take effect and you’ve just disabled digital driver signing in Windows 7!

Secondly, your folder names under Out-of-Box-Drivers must exactly match the make & model variables as reported by WMI (which is not always what you would expect/hope it would be).  This handy VBScript can be run on any computer and will display those two pieces of information.  We used it while we running DoubleDriver on our reference machine so that we could gather all of the required information/drivers at once.

Just copy this code into notepad and name it something like DisplayModelInfo.vbs.


strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem")
For Each objItem In colItems
 WScript.Echo "In MDT Variable Make will be: " & objItem.Manufacturer
 WScript.Echo "In MDT Variable Model will be: " & objItem.Model
Next

How to Correct RBAC Permissions for Distribution List Membership Management in Exchange 2010

If you have just installed Exchange 2010 and are experiencing an issue with end users’ not being able use Outlook to add members to distribution groups they own, there is now a “fix” for it.  I say fix with air quotes because, according to Microsoft, nothing is really broken, it’s by design with the new RBAC permissions model.

Matt Byrd with The Exchange Team has an excellent blog article on this at:

http://blogs.technet.com/b/exchange/archive/2009/11/18/3408844.aspx

…with the actual script to fix it located at:

http://gallery.technet.microsoft.com/scriptcenter/8c22734a-b237-4bba-ada5-74a49321f159

After running the script, your end users should be able to manage the membership of any distribution groups they are listed as the manager of.