#Exchange 2010 on VMware


From NetApp .. Huumm .. http://communities.netapp.com/docs/DOC-7535?REF_SOURCE=tot-1009&h

When you think about running Microsoft® Exchange 2010 on VMware®, it’s easy to come up with good reasons for doing so:

  • Better utilize your processor cores. Large, multicore servers are becoming the norm, but most applications cannot take advantage of all the cores in a physical server.
  • Isolate roles without adding hardware expense. Exchange 2010 has evolved into a modular architecture with distinct server roles, including mailbox, edge transport, hub transport, and client access. Isolating these roles can make it much easier to troubleshoot Exchange problems, but that would require a lot of physical servers, especially in smaller environments.
  • Avoid overprovisioning. It’s always hard to know what the future is going to mean in terms of your Exchange requirements. Running Exchange on VMware means you can provide the right resources now and add them incrementally as you need them, avoiding expensive overprovisioning upfront.
  • More easily meet your business requirements. The way you design your Exchange deployment might depend on your specific requirements. Do you need to have a separate mailbox server for each department or business unit? Virtualization makes it simple to accomplish that without raising your hardware expenses and physical server count.
  • Provision a new Exchange server rapidly. Provisioning a physical server is time consuming, even when you already have the hardware. With VMware it’s easy to create a template for each type of Exchange server and save them to speed the deployment of servers of the same type in the future.
  • Maintain an Exchange lab. Need to maintain a lab to test and troubleshoot Exchange? VMware virtualization is a great foundation for your Exchange 2010 evaluation and testing processes.
  • Clone for testing and troubleshooting. Snapshot™ copies and clones give you the power to rapidly clone a particular Exchange VM for troubleshooting.

Despite these and other advantages, there are several questions that I hear almost every time I talk to people about running Exchange on VMware. In this article, I’m going to try and address the most common concerns and provide some best practices associated with running Exchange in joint VMware and NetApp® environments.

#Powershell to import AD OU Structure from a CSV

So the next step to this post (#Powershell to export AD OU Structure) is to import the OUs.  This is quite simple and uses ADSI to create new OUs.  The CSV need to have atleast a column called Path, and that could be in this format:

“AdministrationGroupsDomain Local Groups”
“AdministrationGroupsGlobal Groups”,

The script will then reverse the path and convert it to a DN and create the OUs.  If the OU exists, the script will error and continue.  Enjoy


$CSVin = Import-Csv c:psOUs.csv
$OUs   = $CSVin | Sort Path

#CSV file need to have atleast a column called Path

$CurrentDomain = [System.DirectoryServices.ActiveDirectory.Domain]::getcurrentdomain()
$DC            = $CurrentDomain.FindDomainController().name + “:389″ #”localhost:389”
$Forest        = $CurrentDomain.Forest.ToString()
$Forest        = “dc=” + $Forest
$Forest        = $Forest.Replace(“.”,”,dc=”)
$domain        = [ADSI]”LDAP://$dc/$Forest”

ForEach($OU in $OUs){
  #Using the OU Path from the CSV File, split it down
  $tmpOU = $OU.Path.Split(“”)

  #Reverse the Path and make it AD happy
  $ActualOU=””;For($i=$tmpOU.Length;$i–;$i -eq 0){IF($tmpOU[$i] -ne “”){$ActualOU+= “OU=” + $tmpOU[$i] + “,”}}

  #Remove the trailing comma
  $ActualOU = $ActualOU.Substring(0, $ActualOU.Length-1)

  #Add the OU.  If it exists it will error but continue
  $NewOU = $Domain.Create(“organizationalunit”, $ActualOU); $NewOU.SetInfo()

Next step is to import users and groups from a CSV .. coming soon.

#Powershell to export AD OU Structure

So I am messing around with a testlab and wanted the OU structure I have in production.  So I wrote this :-D to export the OUs.  The result is a CSV file with two columns Path and OU.  Path is just the OU DN in reverse, and in a “nice” view, so you can sort the OUs.

The script uses .net objects to get domain, forest and DC information.  It uses this to perform a search for all objectcategory that is equal to organizationalUnit.

The script also removes any domain / forest information, so it becomes more generic and can be imported anywhere with out worrying about where it came from.

$CurrentDomain       = [System.DirectoryServices.ActiveDirectory.Domain]::getcurrentdomain()
$DC                  = $CurrentDomain.FindDomainController().name + “:389″ #”localhost:389”
$Forest              = $CurrentDomain.Forest.ToString()
$Forest              = “dc=” + $Forest
$Forest              = $Forest.Replace(“.”,”,dc=”)
$domain              = [ADSI]”LDAP://$dc/$Forest”
$Dom                 = “LDAP://” + $Forest
$Root                = New-Object DirectoryServices.DirectoryEntry $Dom
$searcher            = New-Object DirectoryServices.DirectorySearcher
$searcher.PageSize   = 1000
$searcher.filter     = “(objectcategory=organizationalUnit)”
$searcher.SearchRoot = $root
$objs= $searcher.findall()
$domainDN = $domain.distinguishedName

“Path, OU, Type” | Out-File c:psOUs.csv
ForEach($OU in $Objs){
  $tmpProps = $OU.Properties
  $tmpType = $tmpProps.objectcategory | Out-String
  $tmpType = $tmpType.Trim()
  $tmpType = $tmpType.Substring(0,$tmpType.IndexOf(“,CN=”))
  $tmpType = $tmpType.Replace(“CN=”,””)
  $tmpOU   = $OU.Path
  $tmpOU   = $tmpOU.Replace(“LDAP://”,””)
  $tmpOU   = $tmpOU.Replace(“,$domainDN”,””)
  $tmpPath = $tmpOU.Split(“,”)
  $x=””;For($i=$tmpPath.Length;$i–;$i -le 0){$x+= “” + $tmpPath[$i]}
  $x = $x.replace(“OU=”,””)

  $tmpCSV = [CHAR]34 + $x + [CHAR]34 + “,” + [CHAR]34 + $tmpOU + [CHAR]34 + “,” + $tmpType
  $tmpCSV | Out-File OUs.csv -append

notepad c:psous.csv

Let me know what you think  … Next step is to import them

INFO-SEC: Alert – New Mass Mailer Worm Affecting Some Exchange Customers

#Exchange #Exchange2010

Received this from a number of different people today (Thanks Mitch!)

Emerging Malware Issue: Visal.B: http://blogs.technet.com/b/mmpc/archive/2010/09/09/emerging-malware-issue-visal-b.aspx

Worm:Win32/Visal.B is a new worm, written in Visual Basic, that is currently propagating in part using social-engineering. We strongly encourage customers to be cautious about clicking suspicious or even simply unexpected links in email, even if it’s sent by someone you know. Getting infected by Visal.B is an example of what happens if you aren’t careful.

The threat has a timestamp of 9/3/2010 and spreads using two techniques: mass emailing, and copying itself to local drives (C: and H:) and network shares. The threat will copy itself to various drives on the local system along with an autorun.inf file, and will also send itself to all contacts that it can find on the compromised system via email.

Visal.B uses MAPI to perform a mass mailing to all contacts that it finds on the compromised system. In a corporate environment the “address book” may be extensive. As more machines on a corporate network are infected, more and more email is sent around on the local network, which can cause mail server performance degradation. The threat also sends back information about the compromised system, specifically IP addresses and system information via a built-in SMTP/ESMTP (mail-transfer) engine.

Microsoft Malware Protection Center Technical Summary: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3aWin32%2fVisal.B

Microsoft Malware Protection Center Latest Definitions: http://www.microsoft.com/security/portal/Definitions/ADL.aspx

Microsoft Malware Protection Center Blog Post: http://blogs.technet.com/b/mmpc/archive/2010/09/09/emerging-malware-issue-visal-b.aspx

Microsoft TechNet Wiki on Visal-b: http://social.technet.microsoft.com/wiki/contents/articles/worm-win32-visal-b.aspx