TsooRaD: e2k7

Showing posts with label e2k7. Show all posts

2015/07/15

Windows PKI SHA-1 to SHA-2

(How do you hear me now?)

Thanks go to fellow CDW co-workers Dean Sesko, Russell Despain, and Keith Crosby

What is the issue here?

Basically, the issue is that SHA-1 for PKI is going away in favor of SHA-2, and you WILL have customers that need help with this.

Reference:

AND…?

Any Microsoft supported operating system, properly patched/upgraded, and any Microsoft supported application, again properly patched/upgraded, will support SHA-2 PKI certificates.

Reference:

http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

…there are some caveats: notably around XP and Server 2003, and oddly, Server 2008.

Reference:

So, there is not an issue with Microsoft supported products; the issue is with BYOD and Microsoft making a HUGE effort to support alternative browsers and operating systems. And those browsers and operating systems are fixing on deprecating their support of SHA-1.

Reference:

However, there are going to be numerous AD internal CA’s out there that are issuing SHA-1 certificates, and depending on how the environment is configured, the customer will need to renew their application certificates for internal use. Logically, it makes sense that the desirable outcome of renewing the application certificates is that the issuing PKI be SHA-2.

CDW AD resident experts advise instantiating a new Root CA, and if needed, a new subordinate CA for issuing SHA-2 certificates. But, you know those pesky customers, they may not want to do this. Which would call for modifying the existing structure to hand out SHA-2 vice SHA-1.

Reference:

https://technet.microsoft.com/en-us/library/dn771627.aspx

Experimentation over the last several hours has revealed the following:

Migrating the existing SHA-1 CA went just fine.
The new SHA-2 Root Certificates updated almost immediately into the Trusted Root

I was able to request new SfB certificates and they were issued by the CA based on the new 3DES/SHA-2 root
- However, the host server was not able to chain them up into the Trusted Root.
- I rebooted.
- I ran GPUpdate –force
- I rebooted.
After waiting overnight, THEN the new certs chained up properly. Why this delay in chaining to the new Root I have no idea. I suggest that if you do this for real, that you do the work on one day and then plan on waiting for at least 8 hours before attempting to get new certificates and expecting them to chain up to the new root.

Testing:

After updating the internal certificates on my SfBSE to a new SHA-2 I successfully tested

using Win8.1 and Win7sp1
- IE 11
- Chrome Version 43.0.2357.134
Surface Pro 2 (8.1) IE
iPad (iOS 8.0.2) Safari

Firefox 39 fails – due to it not liking the root cert – why is FF so blinking difficult? Why does it have to have its’ own key chain? The O/S has the root cert! It does this same shit when installed on *nix. After manually importing my new root cert, it worked just fine.

SIP Phones. I had to restart services (stop-cswindowsservice start-cswindowsservice) AFTER I changed the certificate to the new SHA-2 certificate before my AudioCodes 420HD and Polycom VVX-600 would log in. Why, I do not know.

The SfB/Lync Connection!

You may have been wondering why *I* am worried about this. Well, on literally every project with which I have been involved over the last few years, they all had *nix and Mac workstations, along with loads of iPhones, iPads, *nix tablets, droids, surface tablets, and here and there the odd Windows phone. And, you have to know that, in most cases, all of these were attached to an internal corporate wireless. And in some cases, the internal wireless was dropping these devices into the production network, which put them in a position to being able to directly contact Lync/SfB resources on internal servers, that, for the most part, had a PKI certificate from an internal CA. With SHA-1. You knew it had to be simple, right?

Any input to solving/addressing the observed delay would be most welcome. I, for one, totally expected to have the new certificate chain immediately – the appropriate root cert was in place!

YMMV

2013/12/19

Exchange 2007 mailbox users Lync EWS

Scenario

During the transition to Exchange 2013 from Exchange 2007, Exchange Web Services (EWS) integration for Lync will be unavailable for users whose mailboxes remain on Exchange 2007.

The Bad News

Jeremy Silber has an excellent blog article on this issue. It bears reading if you fit the above scenario. Jeremy shows in extremely clear detail what is going on, and why. Unfortunately, he also shows that there is no fix. Here is the article:

http://silbers.net/blog/2013/12/19/lync-ews-broken-during-exchange-20132007-transition/

YMMV

2012/10/02

Private Domain Certificates

Today, you can get a public Certificate Authority - DigiCert, Entrust, etc – to issue you a trusted certificate for your internal domain. For instance, if you have an internal AD name such as domain.local, or domain.tld, or any other that is not registered according to the governing body, then your certificate provider will issue you a certificate for the FQDN of your internal servers and your devices will trust that certificate providing your devices trust the issuer – standard fare for most of the public CA issuers.

In an effort to tighten security on the Internet by creating more stringent standards, the CA/Browser Forum recently formulated new guidelines in their Baseline Requirements for issuing SSL certificates.

One of the new changes is the elimination of certificates using internal names. This change makes it impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as being owned by the organization that is requesting the certificate. According to this CA/Browser document:

Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.

In addition, it appears that internal name certificates will NOT be issued after 1 Nov 2015. Or, at least DigiCert will not issue them after that date:

In accordance with this new standard, DigiCert will no longer issue certificates to these internal names with expiration dates after November 1, 2015.

If you fall into this category, you should begin planning now to: a) deploy internal PKI and figure out how that action will change your environment(s); or b) change your internal AD DS name (yuk!).

Interesting note: www.digicert.com is already planning ahead to help you out! See this nifty tool.

YMMV

2012/01/20

Discover E2003 Relay IP

Situation

Faced with discovery and documenting “hundreds” of potential IP’s in the relay lists spread across 14 e2003 servers, I went looking for a more programmatic methodology.

Potential Solution

Found this: http://support.microsoft.com/kb/935635

While the output is a little clunky, it works way better than me writing them down manually, or screen shots. The reference KB would have you do this from an Exchange server. I am using a domain workstation with good results. With a little excel work, I will be able to combine all this into one PS script to create receive connectors in E2010.

This is probably old info to some of you. YMMV.

2011/12/30

Create CSR from TMG

Scenario

You need to create a Certificate Signing Request (CSR) for your TMG to support Lync (or Exchange or whatever) - AND you need this certificate to have SAN (Subject Alternative Name) entries.

What to do?

Chad McGreanor has a great write-up on this!

Changes?

If you do not already have a Local Computer Certificates\Personal\Certificates container in your TMG deployment, you can still use this process – by accessing the CSR process as shown here:

YMMV

2011/12/28

OAB and GAL issues

Situation

I just spent the last 3-4 hours doing this research for some random issues as listed below. What resulted was a pretty comprehensive Tshoot OAB/GAL issues outline. Thought I would share.

Issue is (seemingly) random users get created but never show in the GAL – no pattern.

Issue is (seemingly) random users cannot see all users in GAL – no pattern.

- If you create a brand new Outlook profile on a newly installed client with a newly created account, in cached mode, are you able to download a full OAB successfully (this happens automatically with a new OL profile).

o If yes, do you see the "missing" account ?

o If yes, then the OAB is the correct one, and is correctly being updated.

- If no, you have a problem with syncing your OAB. It should point only to the GAL and if it does, and there are no sync errors, it MUST contain the errant account if this appears correctly in the GAL.

The answer to the short experiment above drives which of the following choices to pursue.

1. Can you see the Contact if you turn off Outlook Cached Mode?

2. Does the Contact resolve in Outlook Web Access?

3. Can others see the Contact?

4. Ensure that the user’s default external e-mail address and the windows e-mail address (AD attribute) are exactly the same.

5. If you have a client in cached mode that is not updating the OAB, remove/rename *.oab files in their %userprofile%\Local Settings\Application Data\Microsoft\Outlook. Next time you start Outlook it will re-download the address book and create new OAB files. The problem was the oab files got corrupt and would not catch new updates.

6. If it continues to happen, try excluding these oab files from your anti-virus scanner.

7. Recreate the users Outlook Profile and download all the content fresh

8. folder underneath OAB named d33d3462-etc-etc where the OAB resides had read only permissions set for authenticated users. The OAB folder did not have that permission.

9. On the e2010 server, make sure the Microsoft exchange file distribution service is running.

10. Make sure the recipient that does not show up has an x500 address entry

11. Does anything show in a BPA from e2003?

12. Does anything show in a BPA from e2010?

13. Which server is the OAB generator? Anything in the event log there?

14. Make an e2010 server the OAB generator

a. Any ol2003? Then you need PF distribution

b. Only OL2007 or higher? Use e2010 and web distribution

These seem fairly on point:

http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/b12fb4e6-9da2-450e-b994-0b90eb5252bc/

The domain controller that you are using for OAB gen specified in the 9117

event isn’t seeing that user. Make sure there is not a 9325 in the

application log skipping him because of a bad attribute. You can download a

copy of OABInteg from http://code.msdn.com/oabinteg. Use an online profile

and run oabinteg /s:srvname /t:proxytest /v:2 /l and look at the errors in

the log.

Try deleting the user's oab files then have him redownload.

Go to C:\Users\username\AppData\Local\Microsoft\Outlook

Delete all files with .oab

Outlook, send\receive download address book.

Also did you move this user to another new mailbox store? If so make sure the mailbox store has been set to use the default OAB.

Exchange 2007/2010 Web services and Autodiscover Ultimate Troubleshooting Guide

I decided to put this ultimate guide to spare the hustle and allow smoother and nicer web services experience.
Well, let us first list the directories that are used in the Exchange web service:

· EWS is used for OOF, Scheduling assistance and free+busy Lookup.
OAB provides offline address book download services for client.
Autodiscover is used to provide users with autodiscover service.
EAS provides ActiveSync services to Windows Mobile based devices.
OWA provides outlook web access for users.
ECP provides Exchange control panel feature for Exchange 2010 users only.

Issues that might be resolved using the troubleshooting steps here:

· You cannot set the OOF using outlook client, you receive the server not available error.
You cannot view free/busy information for other users.
You cannot use scheduling assistance, also you might receive not free/busy information data retrieved.
You cannot download Offline Address book errors.
You cannot use autodiscover externally.
Certificate mismatch error in autodiscover, users prompted to trust certificate in outlook 2007/2010.

I will update this post to include all of the errors that I face and solve in my work or on EE to help experts all over EE to quickly solve their issues.
First let us start by the configuration required post Exchange 2007/2010 installation for the above to work correctly:
Configure External and Internal URLs for OWS, ref: http://technet.microsoft.com/en-us/library/bb691323(EXCHG.80).aspx

· You have to configure the internal URL to be the server name in case you have multiple servers in NLB.
External URL will be the URL used by users to access webmail e.g. https://mail.domain.com/owa
Mail.domain.com in multiple CAS servers will be the NLB FQDN.
Configure External and Internal URLs for OAB, ref: http://technet.microsoft.com/en-us/library/bb123710.aspx
This will point if multiple CAS servers are used then this will point to NLB FQDN.
If single server used this will point to the internal server FQDN in the internal URL, and the mail.domain.com which is used by webmail users.

Configure the autodiscover internal URL:

· You will use the powershell cmdlet : Set-ClientAccessServer –Identity <CAS Server Name> -AutoDiscoverServiceInternalUri: <Internal URL>, this FQDN must match the URL included in the certificate.
If you cannot use autodiscover.domain.com internally (you have a domain name of domain.local and you must use it), you will get a certificate miss match error, you will have to include the internal name in the certificate if you purchase an external certificate.
If you have multiple CAS in NLB this will be the NLB FQDN.
You cannot set autodiscover external URL since outlook will try to access https://autodiscover.domain.com/autodiscover/autodiscover.xml, this behavior is by design and cannot be changed.
Autodiscover.domain.com must be included in the certificate that you assign to IIS if you purchasing a certificate externally from 3rd party provider.

Configure EAS internal and External URLs, ref: http://technet.microsoft.com/en-us/library/bb629533(EXCHG.80).aspx

· This URL will point to the NLB FQDN internally
This IRL will point to NLB FQDN Externally.

Configure the EWS (which provides availability, OOF) internal and external URLs

· You can set the internal FQDN and External FQDN using: get-webservicesvirtualdirectory | Set-WebServicesVirtualDirectory –InternalUrl: https://url.domain.local/EWS/Exchange.asmx –ExternalURl: https://url.domain.com/EWS/Exchange.asmx

after all of the above settings you have to take into considerations the following note:

· All of the above uses https connection, so SSL certificate must be configured and assigned to IIS on the CAS servers.
Since all of the above uses https, if you have a proxy traffic might be affected.
Make sure that clients can access the URL internally and externally, you can do that by going to the above URL using IE or Firefox and validate that you can access them.

For some people after doing the above configuration you still receive some errors so make sure of the following:

· IIS is started.
OWA application pool, OAB application pool and EWS application pool are running and started with no errors
If you receive authentication error, error 500 service not available, error 400 login time out, or unspecified error you will need to rebuild your virtual directories. You can do that as following:

· For OWA:
Get-owavirtualdirectory | remove-owavirtualdirectory
New-owavirtualdirectory.
You can repeat this step for EWS (webservicesdirectory), OAB (OABvirtualdirectory) and autodiscover(autodiscovervirtualdirectory)

You will have to note that you will need to re-configure any customizations you made to OWA after removing and deleting it, also you will have to redo any internal and external URL configuration you have did in the past

Troubleshooting Offline Address Book Generation on Exchange 2010

After migrating from Exchange 2007 to Exchange 2010, we began noticing that address book downloads failed during a manual send/receive operation with:

‘error (0x8004010F) operation failed. An object cannot be found.’

Basically, this error is happening because Outlook 2007 and higher clients rely on web based distribution of the offline address book, and that address book is not found on the CAS Server.

The fix is to enable the Default Offline Address book on the mailbox server for Web-based distribution:

This setting does not go into effect immediately. If you want to force it to start working immediately, you need to perform these steps:

1) Update the address book

2) Restart the File Distribution Service on the CAS Server

Performing this step will cause the CAS to download a copy of the OAB from the Mailbox server, see this post for more info on the Exchange File Distribution service.

3) Force Active Directory to sync (repadmin /syncall /APed)

Now, when you force a send/receive from Outlook, the address book will download cleanly!

There are other reasons why clients may be getting error 0x8004010F, check out this post for more information: http://blogs.msdn.com/dgoldman/archive/2008/10/01/understanding-why-error-code-0x8004010f-is-thrown-when-trying-to-download-an-oab.aspx

Also, if you are getting Event 9320 in your event logs, you can safely ignore those per this blog:

http://blogs.msdn.com/dgoldman/archive/2009/12/01/please-read-events-9320-and-9359-on-new-installation-of-exchange-2010.aspx

2011/12/12

Lync 2010 & Exchange UM Integration

If you are deploying Lync Server 2010 with Exchange 2010 Unified Messaging, then this guide is your friend.

The sections of this document help you understand how to deploy and troubleshoot this vital UC component interaction to include conducting testst using synthetic transactions.

YMMV.

2011/10/21

RUS Issue #2 (ExBPA)

Situation

First off, you would think the ExBPA would be smart enough to recognize this situation and not behave this way, but that is a subject for another post.

The E2010 Exchange Best Practice Analyzer (ExBPA) throws the following error when run against a new E2010 install. The environment originally came from E2003, then moved to E2007, now moving to E2010. The E2003 was removed 18 months or so ago…

This link from the ExBPA gives some great information provided you are still running E2003. If you are not, what to do?

There are a variety of resources in google-land that will advise you to just ignore the errors messages. As an example, here is one with an Exchange MVP advising against doing some drastic like removing whole containers from the configuration. Sembee gives great advice. But what if you don’t like seeing those Red X notices? What if your boss does not like them and judges you accordingly? Let’s see if we can do something non-invasive to remove this specific error.

The Fix (NOT SUPPORTED!)

Read the first link above, and then attempt to digest this part of it:

The Microsoft Exchange Server Analyzer Tool queries the Active Directory directory service to determine the value of the msExchAddressListServiceLink attribute for each Recipient Update Service object in the directory. The msExchAddressListServiceLink attribute is a link from the address list service to the Exchange Server computer it should be running on. If the Exchange Analyzer finds that there is no msExchAddressListServiceLink attribute for a Recipient Update Service object, or the msExchAddressListServiceLink attribute value for the object is not populated, an error is displayed.

How does this translate into reality? From an ADSIedit viewpoint, we can see the RUS container is very much still in AD (the reference environment came from E2003). In this view, I am showing the actual attribute on the domain RUS object.

So, this is why the ExBPA is pitching the error. What do we put in there to remove the error. Well, the name of an Exchange server of course! But what format and where can I get it?

Here is the format:

CN=E2010,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=domain,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com

And here is where you can get this wonderful data string:

Plug this into the attribute of the RUS object as shown:

Depending on which DC/GC you are talking to with what server, wait 15 minutes or so for replication to occur, then re-run ExBPA. The RUS error will now be gone. Please note that this is visual only, E2010 ignores the RUS containers as RUS no longer exists in E2010 (E2007 for that matter).

This is NOT a supported fix. I suppose if you are still running E2003 and get this error, you could use this to resolve that instance as it illustrates the guidance of the recommended fix.

The Fix #2 (Supported)

After doing a bit more research, and reviewing exactly how to remove E2003, I realized that removing the RUS is part of the process:

Perform the following steps to delete the domain Recipient Update Services:
1. In Exchange 2003 or Exchange 2000 System Manager, expand Recipients, and then select Recipient Update Services.
2. Right-click each domain Recipient Update Service, and then select Delete.
3. Click Yes.
You will not be able to delete the Recipient Update Service (Enterprise Configuration) by using Exchange 2003 or Exchange 2000 System Manager. Perform the following steps to delete the Recipient Update Service (Enterprise Configuration) by using ADSI Edit (AdsiEdit.msc):
1. Open ADSI Edit, expand Configuration, expand CN=Configuration,CN=<domain>, expand CN=Services, expand CN=Microsoft Exchange, expand CN=<Exchange organization name>, expand CN=Address Lists Container, and then select CN=Recipient Update Services.
2. In the result pane, right-click Recipient Update Service (Enterprise Configuration), click Delete, and then click Yes to confirm the deletion.

YMMV

2011/08/16

Maximum Number of names in a SAN Extension

In what is sure to be a long standing record (of sorts) for me (and maybe only me) – I just submitted a CSR to a public provider with 53 domains in the SAN field. This raised the question: “how many entries or names can be in that one field?” I know there has to be some sort of limit.

Handy Dandy, we had a TMG guy in the room, so we asked him. While he did not know off the top of his head, he did have an answer in mere minutes (where I had googled for about 10 and found squat).

http://social.technet.microsoft.com/wiki/contents/articles/3306.aspx

So, now we know the field is defined by a database, that a Windows PKI CA is limited to 4k of names, and that somewhere around 150 25 character domain names eat up just under 4k. By extension, we can assume (and we know what that means) that the Public cert providers are following the same RFC and that they will have a similar limit.

How about that? An answer to a question you did not know you had!

YMMV

2011/06/20

Open Services applet in Standard Mode

Ever since somebody at Microsoft decided we needed the services.msc applet to open in “extended” mode, I have been clicking on “standard” to get the view I wanted. This last week I finally got fed up with this, and decided to do something about it. As it turns out, this is not the easiest thing to change. Apparently, us poor users are not allowed to change the behavior for the named services.msc. We are not worthy.

What you have to do is author a new named instance – and of course remember to use that one. I was unsuccessful at renaming, deleting, or otherwise removing the original services.msc. I am sure there is some method to do so, but I was unwilling to dink too much with an operating system that was working before I messed with it. YMMV.

Here is what I did: (the example is using an x64 Win7 O/S, but it works equally well for Server 2008, and I imagine, Vista (why are you using that?).

Go to c:\windows\system32 and locate the services.msc applet. Right-click it and select “author.”

When services opens, click File | Options as shown.

Now, change that console mode to “author.”

Say OK to this…

Change the view to standard…

Now, save this to a name and location of your choosing…

Now when you go to a command line (or in my case about 90% of the time a powershell prompt), and type in jmwservices.msc, I get this “new and de-proved” services applet in standard mode. I suppose you could mod the original references to the new applet if you want to get fancy.

Enjoy!

2011/03/10

Update Rollup 3 for Exchange 2010 SP1 and Exchange 2007 SP3

EHLO has announced the following updates for Exchange 2010 and Exchange 2007. See the details here.

2010/11/05

No ringback in Lync

I just did a deployment where the PSTN was a Nortel and we used an AudioCodes 1000 gateway. Everything worked out well until we noticed that outside calls coming through the Nortel got dead air until the Lync user either answered the call or Lync sent the call to voice mail.

Seeing as how Lync to Lync calls behaved properly, and tracing showed the proper SIP 180 responses, the obvious culprit was either the gateway or the Nortel. Turns out that in an AudioCodes gateway there is a setting for allowing ringback to leave the system and head for the PSTN!

Now, I am not a gateway guru, but don’t you think that would be a desired thing to have? Well, it is off by default. Flip it over a bit and voila! Ringback to PSTN.

2010/07/21

single cert for ocs/exchange

this is a rewrite of previous post that got thrown away somehow…

Single certificate for OCS/Exchange firewall usage

Certificates can be complicated to understand, difficult to manage, and if you don’t have an internal PKI structure, downright expensive as you move forward with more and more dynamic applications that extend your Unified Communications to your remote users and business partners.

Internal certificates work wonders for your Active Directory Domain Services members. For Unified Communications, where OCS and Exchange are going to be using the same ISA 2006 server as the firewall, utilizing a Subject Alternative Name (SAN) certificate for your edge configuration and your ISA configuration can save you time, management hassles, and possibly provide cost savings as well. For internal servers, an internal PKI is just fine, but for the public interface of your system, you should most likely be looking at using a public-sourced key such as Go-Daddy, Thawte, DigiCert, etc. OCS Federation, remote users, and Public Instant Messaging Connectivity (PIC) demand public certificates. I know that I do not want to ship my internal CA root certificate to a slew of administrators and expect them to get that certificate into the correct spot for our systems to co-exist. But I digress.

The following table shows the SAN names needed on a certificate to support the base OCS and Exchange functions on ISA 2006/TMG/UAG – and I imagine that this certificate construction will work just fine on many other firewalls as well. The table comes from my test domain; you should replace my test domain with your own domain name.

Obtain a public SAN (UCC) certificate from your favorite provider; import the certificate into your OCS Edge server and your ISA server computer account Trusted Root Certificate store and then you can use one certificate for all these uses. This approach leaves you with only the one certificate to manage and renew, or, if life treats you badly, move to a new server.

	SAN Name (what URL?)	Usage	Notes
1	SIP.tsoorad.net	OCS Edge Server	IM, Presence, Federation, PIC
2	LM.tsoorad.net	OCS Edge Server	Web Conferencing
3	AV.tsoorad.net	OCS Edge Server	A/V
4	OCS.tsoorad.net	ISA Reverse Proxy	Web Components
5	CWA.tsoorad.net	ISA Web Listener	Communicator Web Access
6	DOWNLOAD.CWA.tsoorad.net	ISA Web Listener	Cname for CWA desktop sharing
7	AS.CWA.tsoorad.net	ISA Web Listener	Cname for CWA desktop sharing
8	MAIL.tsoorad.net	ISA publisher	Outlook Anywhere, EAS, OWA, POP, IMAP
9	AUTODISCOVER.tsoorad.net	ISA Web Listener	Autodiscover is used by outlook and OCS.

2010/06/23

iPhone VM & Exchange

A day late and a dollar short…

I have been using my iPhone for VM and I had forgotten how I set the mailbox for iPhone support. So I flailed around a bit and then remembered that Tom Pacyk had the info on his blog….

And now it will be here also, so idiots like me don’t forget where to find the info.

set-ummailbox identity –callansweringcodec gsm

You can use g711 also, but it makes huge files.

Exchange 2010 does MP3 as the default, I believe, audio files for VM so this should not be an issue if you have Exchange 2010.

2009/09/15

Exchange 2010 OWA and IE

It appears that there are significant differences between the IE versions and how OWA displays and operates with Exchange 2010 RC.

IE7 is the minimum to get the premium OWA; IE6 gets you OWA lite.

2009/08/20

DL Management from Outlook

Exchange admins typically add/remove members from distribution lists. However, as the organization grows in numbers and complexity, this situation needs addressing.

You would think that simply adding the appropriate user to the DL manager as shown would work, but that is not the case.

You will also need to do a little add-adpermission tweaking like this (the line may wrap):

add-adpermission -identity: “DL Group1” -User:domain\joe.tester -accessrights readproperty, writeproperty -properties ‘member’

you can add a group to this also:

add-adpermission -identity: “DL Group1” -User:”display name of permissions group” -accessrights readproperty, writeproperty -properties ‘member’

After this, the user should be able to open the DL from the outlook address book and modify the member list. If you have a multiple domain scenario and this does not work, you have a global catalog issue.

My thanks to http://knicksmith.blogspot.com/2007/04/delegating-distribution-group.html for pointing me in the right direction to remember what I had forgotten. Thanks Nick!

2009/03/17

Install Exchange 2007 SP1 prerequisites on Server 2008

Note: No Server 2008 Core - must be full version

This does NOT cover setting up for clustering.
This does not cover NLB

I don't think you can have an Exchange Server without having PowerShell or the management tools; therefore, you will see that each section has PowerShell and management tool support. By having the management tools on each server, you will be able to manage the Exchange Organization from any role server. Exchange 2007 server should have things like dsa.msc, so you will also see the RSAT-ADDC install listed. I also think that not enabling the Outlook Anywhere (RPC/HTTP) is a crime, as is not using SSL on that component, so you will see that listed for the CAS role also (although not the SSL part).

At the very bottom, you will see a "single server" section that will install ws08 support for a server that will be CAS, HT, MBX, and UM. The first few sections for Powershell, IIS, and RPC proxy are just for reference.

Feel free to cut and paste to fit your needs.

#PowerShell install

ServerManagerCmd -i PowerShell

#IIS

ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression

#RPC Proxy

ServerManagerCmd -i RPC-over-HTTP-proxy

# Mgmt Tools support