Monday, December 31, 2012

Change the iPhone Signal Strength Indicator


This procedure will change the signal strength indicator on your iPhone from the standard "bars" display to a numeric indicator of the actual signal strength in decibels (dBm). The closer the number is to zero, the stronger your signal is. For example, -75 is better than -110.

Step 1: Dial *3001#12345#* on your iPhone then press Call. This puts your phone in Field Test mode, and you'll notice a signal strength indicator in the upper left corner of your screen.

Step 2: You can toggle between the standard bars indicator and a number by simply tapping on it. Once the indicator changes, press the home button to exit the app, or if you would like the feature to be permanent (until you change it again), continue on.

Step 3: Hold down on the Power button until you see the ‘slide to power off’ bar, but do not power off the device.

Step 4: Press down on the Home button until the app closes and you return to your home screen.

That’s all there is to it. Again, the closer your number is to zero, the stronger your signal is.

To return to the default bars permanently, follow these steps:

Step 1: Dial *3001#12345#* on your iPhone then press Call.

Step 2: Press on your Home Button once.


Monday, November 26, 2012

Chasing Down a Linking Problem

If your environment employs a resource domain, or if you happen to have multiple user logon domains (as we do), you're probably familiar with the concept of linked mailboxes in Exchange. We currently have two domains that contain logon accounts, while all of our Exchange servers, and therefore the mailboxes, are in just one of those domains.

Side note: The biggest downside I see to this whole concept of linked accounts is that it's tougher to monitor for inactive accounts, since the resource account used to host the mailbox is never active, never used for an interactive logon. Sure, the user accounts in the linked domain are monitored, disabled when someone leaves, and then purged regularly, but the associated resource account and mailbox can hang around for moths or even years. Security is more worried about interactive logons instead of stale data, so there's really no one that sees this as a problem.

This morning I ran into a little problem with one of these old accounts, and a former employee that had come back again. When he left, sometime last year, his account was disabled and moved into a "Retired Users" OU. His mailbox account had been untouched, and was still collecting mail ever since he left. I decided to delete the old mailbox and create a new one, so he could start out fresh. Note that I only removed the Exchange attributes from his resource account. I didn't delete the account, just the old linked mailbox.

Using the mailbox wizard (I'm lazy), I repeatedly tried to create a new linked mailbox, using both of his old accounts, but ran into a snag - the wizard couldn't find his logon account. The resource account in the Exchange domain was just fine, but his logon account (which had been re-enabled and moved into a production OU) would not show up in the wizard when it listed the accounts available to be linked. I spent a couple of hours verifying settings and trying different things in an effort to make the account become visible, to no avail.

Finally, after breaking for lunch, I hit on an idea. On the assumption that the account was visible because Exchange somehow believed that it was already mail-enabled, I looked up an old Exchange team blog article on removing Exchange attributes (http://blogs.technet.com/b/exchange/archive/2006/10/13/3395089.aspx), and then fired up ADSIEdit to see what I could find on the user's logon account, and sure enough, it had several Exchange attributes set. After clearing those attributes, the wizard was quickly able to locate the user's account, and the new linked mailbox was completed.

The underlying cause of the problem was interesting - the user's logon domain had once had its own Exchange organization. In fact, that domain had belonged to another company, which had merged with our company a few years back. When we deployed Exchange 2007 (a couple of years ago), we decommissioned the other domain's Exchange organization and moved them into ours via the linked mailbox model. That's also why we still have two logon domains, one with Exchange and one without. Even though we had migrated the other domain's mailboxes, at least some of the old Exchange attributes were left behind, unused, and one or more of those attributes prevented me from linking the account again because Exchange believed the account was already mail-enabled. How about that?

Thursday, September 13, 2012

EdgeSync Failures After Removing A Child Domain

We have a domain with several child domains. Exchange 2010 is installed in the root domain, and there's also an Edge server installed in our DMZ.

Last week, two of our child domains were decommissioned, and as a result, SCOM almost immediately started throwing alerts related to EdgeSync Enterprise synchronization failures.

******************************
CurrentTime (UTC):09/13/2012 11:01:05
Name:EDGESERVER
SyncStatus:Failed
LeaseHolder:CN=INTERNALSERVER,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=MYEXCHANGEORG,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DOMAIN,DC=LOCAL
LeaseType:Option
LeaseExpiry (UTC):09/13/2012 11:30:19
LastSynchronized (UTC):09/13/2012 11:00:19
Cookie Records (5):
Domain:DC=child1,DC=domain,DC=local; LastUpdated (UTC):09/13/2012 11:00:19; DC:dc1.domain.local
Domain:DC=domain,DC=local; LastUpdated (UTC):09/13/2012 11:00:19; DC:dc1.domain.local
Domain:CN=Configuration,DC=domain,DC=local; LastUpdated (UTC):09/13/2012 10:59:52; DC:dc2.domain.local
Domain:DC=child2,DC=domain,DC=local; LastUpdated (UTC):09/06/2012 19:15:52; DC:dc1.domain.local
Domain:DC=grandchild1,DC=child2,DC=domain,DC=local; LastUpdated (UTC):09/05/2012 21:05:11; DC:dc1.domain.local
Failure Details:The EdgeSync cookie has not been updated as expected. It may indicate EdgeSync has encountered synchronization errors. For more information, check the EdgeSync logs.
Diagnostic command: "Test-EdgeSynchronization -MonitoringContext:$true"
EventSourceName: MSExchange Monitoring EdgeSynchronization
******************************

I noticed that the cookie records still included the domains that had been decommissioned - grandchild1 and child2. I took to Google and searched on "EdgeSync cookie has not been updated" (in the Failure Details section), and found the following article: http://social.technet.microsoft.com/Forums/nl/exchange2010/thread/c918600c-f233-47dd-9efa-86ecc88d13e9. In the event that that article disappears, it basically says that the ADAM database on the Edge server still contains entries for the domains that had been decommissioned, and since those domains no longer exist in Active Directory, it causes synchronization failures when the edgesync process runs. The solution is to edit the entries in the ADAM database, and remove the references to the non-existent domains. To do that, the following steps must be completed.

1.On the Edge server, open a command prompt and run the following command:

Type "dsdbutil" and then type "list instances", which produces output similar to the following:

Instance Name:         MSExchange
Long Name:             MSExchange
LDAP Port:             50389
SSL Port:              50636
Install folder:        C:\Windows\
Database file:         D:\Exchange\TransportRoles\Data\Adam\adamntds.dit
Log folder:            D:\Exchange\TransportRoles\Data\Adam
Service state:         Running

Make a note of the LDAP port (50389 in this example)

2. Launch ADSIEdit.msc, and open a new connection.

In the Connection Point section, set the well known naming context to Configuration.
In the Computer section, type in the server name (or localhost) followed by the number of the LDAP port you noted in the previous step (Example: localhost:50389)
Click OK to connect it.

3. Expand Configuration > Services > Microsoft Exchange > First Organization > Administrative Groups > Servers > (name of edge server)

Right Click the server object and locate the attribute called msExchEdgeSyncCookies and edit the attribute to remove any DC's that no longer exist.

4. Back on the internal Exchange server, open an Exchange Management Shell and run "Start-EdgeSynchronization -ForceFullSync -ForceUpdateCookie". This may take some time, depending on how many recipient objects exist in your organization. We've got around 12,000, and it took about a minute and a half to complete.

5.Now run Test-EdgeSynchronization again. Assuming the entries in your ADAM database match what's in your Active Directory now, the test should complete successfully, and SCOM should no longer throw any alerts.


Saturday, August 25, 2012

Bulk Creation of Mail-Enabled Security Groups

During our recent implementation of System Center Service Manager 2012, I was asked to create several dozen mail-enabled security groups. After some discussion around naming conventions, I was provided with a CSV file containing the desired display names and aliases, that looked like this (this is only a partial list):


Display Name,Email Alias
ACCOUNTING,smaccounting
AUDIT  COMPLIANCE,smauditcompliance
AUSTRALIA,smaustralia
BACKUP ADMINS,smbackupadmins
CANADA,smcanada
CHANGE MANAGEMENT,smchangemgmt


In order to organize and differentiate these groups from similarly named groups that already existed in our directory, each group's display name would be prefixed with "zSvcMgr". The "z" pushed these entries down to the bottom of the address list where they would be less likely to be seen or used, yet they would still be grouped together alphabetically. The email aliases would also be prefixed by "sm". As you can see from the above sample list, the supplied file included the "sm" prefix on the email aliases, but the "zSvcMgr" prefix is missing from the display names. I'll have to add those in during the processing.

This is one of those situations where a script would be handy, but the single-use nature of the task doesn't really warrant a lot of development time. I decided to just write the code on the fly, but this could easily be turned into a full-fledged script if you need to do this sort of thing often.

I basically needed to do two distinct things - process each line in the CSV file to create the security groups and then mail-enable them. Creating the groups could be done from any standard powershell session, but mail enabling them requires the Exchange shell, so I just performed both tasks from an Exchange 2010 shell session. Here's all the code I needed to complete the job.

$list = Import-CSV SMGroupList.csv

Import-module ActiveDirectory
foreach ($entry in $list) {
$name = "zSvcMgr " + $entry."Display Name"
$alias = $entry."Email Alias"
New-ADGroup –Name $name –Path “ou=ServiceManager,ou=Distribution Lists,dc=mydomain,dc=pvt” –GroupScope universal
Enable-DistributionGroup -Identity "cn=$name,ou=ServiceManager,ou=Distribution Lists,dc=mydomain,dc=pvt" -alias $alias
}


That's all that's required. Let's take a more detailed look at each line.


$list = Import-CSV SMGroupList.csv


This line imports the CSV file into the $list variable. This loads the entire file into memory, and automatically uses the data in the first row as column headings.

Import-module ActiveDirectory

This command loads the Active Directory module into the shell, giving us access to the New-ADGroup command, which we'll use to create our new groups.

foreach ($entry in $list) {

Now we want to start processing the contents of the CSV file, which is stored in the $list variable. The foreach command will loop through the imported data line by line. For each iteration of the foreach loop, the $entry variable will contain the contents of the currently processing line. To access the various fields in the line, just refer to the field by using the column name.

$name = "zSvcMgr " + $entry."Display Name"

In the line above, I build the desired name of the group, taking the contents of the imported Display Name field (note: $entry."Display Name" references the Display Name field in the current $entry variable), append it to the end of the "zSvcMgr " string, then assign the new name to the $name variable.

$alias = $entry."Email Alias"

Next, we grab the Email Alias value from the current line in the $entry variable, and assign it to the $alias variable. Note that the double quotes around Email Alias is only required because the field name has a space in it. If the field name were "EmailAlias" (no spaces), then we could have left off the double quotes and referred to it as simply $entry.EmailAlias.

Now that we've populated our variables, we're ready to create our new group.

New-ADGroup –Name $name –Path “ou=ServiceManager,ou=Distribution Lists,dc=mydomain,dc=pvt” –GroupScope universal

Here, we pass the $name variable, which contains the group name we built above, to the New-ADGroup command. The -Path parameter tells the command where to create the new group object in our Active Directory hierarchy, and the -GroupScope parameter tells it to create a universal group. If you omit the -GroupScope parameter, a global group is created by default.

All that's left to do now is to mail-enable our newly-created group.

Enable-DistributionGroup -Identity "cn=$name,ou=ServiceManager,ou=Distribution Lists,dc=mydomain,dc=pvt" -alias $alias

Note that we're passing both the $name and $alias variables to the Enable-DistributionGroup command. Since we're not specifying a PrimarySmtpAddress parameter, our new group will receive an SMTP address from the default email address policy.


}


The ending curly brace signals the end of our foreach loop, and then the process repeats for the next line in the $list variable. Once all of the lines are processed, all of our shiny, new, mail-enabled security groups will be created. A quick peek inside the ServiceManager OU confirms that the groups exist, and you can confirm that they exist in Exchange by looking in the console, or by issuing a quick, "Get-DistributionGroup zSvcMgr*" command.

That's all there was to it. It took much less to time to write the code and create the groups than it did to write it all down and explain how it worked. I hope someone finds it useful.



Thursday, February 9, 2012

Quick and Dirty Reporting on Distribution List Usage

I was given a list of 50 distribution lists, and asked to report on how often they were used. Time to hit the tracking logs. And we have two hub servers, so I have to query against both servers to get the whole list. Here's what I came up with. For this example, we'll work with 5 distribution lists. I don't want to type in all 50.

# create an array containing the distribution list addresses
$recipients = "list1@sample.com", "list2@sample.com", "list3@sample.com"
$recipients += "list4@sample.com", "list5@sample.com"


# create an array containing our hub servers
$servers = "hubserver1", "hubserver2"


# set the start and end date of the query
$startdate = "2/1/12 12:00 AM"
$enddate = "2/2/12 12:00 AM"


foreach ($recipient in $recipients) {
     $results = @()
     foreach ($server in $servers) {
          $results += Get-MessageTrackingLog -Server $server -Start $startdate -End $enddate -Recipients $recipient -EventId RECEIVE
     }
     Write-Host "$recipient," $results.count    # outputs the distribution list address and the hit count
     Remove-Item variable:results     # delete the results
}

The output is a simple:

list1@sample.com, 12

list2@sample.com, 2
list3@sample.com, 27
list4@sample.com, 423
list5@sample.com, 1

If you need to see the individual message data, just change the code to remove the $results array, like this:

foreach ($recipient in $recipients) {
     foreach ($server in $servers) {
          Get-MessageTrackingLog -Server $server -Start $startdate -End $enddate -Recipients $recipient -EventId RECEIVE
     }
}

Of course, your results are based on the number of tracking logs you have available. Exchange 2010 automatically purges tracking logs based on the settings of the transport server configuration, which defaults to 30 days. If you have enough disk space, you can modify the retention period with the Set-TransportServer command. See this article for more information on configuring message tracking.


Monday, January 30, 2012

Unable to Remove an ActiveSyncDevice from an Account

I’ve noticed an issue sometimes occurs when attempting to remove an activesync device relationship from a user’s mailbox. This behavior happens frequently with users who have left the company recently. All attempts to remove the device via the Manage Mobile Phone action in the Exchange console results in a device not found error. I hadn’t noticed a pattern to this behavior until today.


When a user leaves the company, the help desk usually moves the user’s account to the different OU in Active Directory (in our case, it's the "Disabled" OU). Although each device’s Identity and DistinguishedName properties reflect the new location of the account, it would appear that the Remove-ActiveSyncDevice command only looks at the UserDisplayName property, and that property does not get updated – it continues to reflect the location of the account at the time the device relationship was created. This causes the command to fail, since the object no longer exists at that location in AD. Here’s an example of a device that belongs to a former associate. Notice the highlighted fields, which show two very different locations.

UserDisplayName : domain.local/Field Management/District Managers/Joe Blow
Name : MOTOBLUR30

DistinguishedName : CN=MOTOBLUR30,CN=ExchangeActiveSyncDevices,CN=Joe Blow,OU=Disabled,DC=domain,DC=local
Identity : domain.local/Disabled/Joe Blow/ExchangeActiveSyncDevices/MOTOBLUR30
Guid : e6078fc3-bcff-43c9-a334-8c74e075d558
ObjectCategory : domain.local/Configuration/Schema/ms-Exch-Active-Sync-Device


To work around the problem and remove the device, go to the Exchange shell and run the following command:

Get-ActiveSyncDevice | where {$_.userdisplayname –like “*Joe Blow”} | Remove-ActiveSyncDevice

You will be prompted to confirm each device to be deleted, which is handy if the user has multiple devices and you only want to delete a particular device.

Friday, January 27, 2012

Auditing Administrative Changes in Exchange 2010

Exchange 2010 maintains a hidden mailbox that logs all administrative changes. The "Hey Scripting Guy" blog recently published an article that explains how to retrieve that information with powershell. If you ignore the remoting stuff at the top of the article (that can confuse or discourage some people), the auditing commands can be run directly from the management shell on any of the Exchange 2010 servers. I've always wanted this sort of visibility into who's doing what in Exchange, so I wanted to talk about it some more. But go read this article first:


For example, to get a list of all the new mailboxes created in the last day, use this command:

Search-AdminAuditLog -StartDate (get-date).adddays(-1) -EndDate (get-date) -Cmdlets enable-mailbox

Which produces this output:

RunspaceId         : 7d4bc202-de70-4c2f-a146-263d05445ea8
ObjectModified     : domain.local/Headquarters/Contractors/Cristin Broom
CmdletName         : Enable-Mailbox
CmdletParameters   : {Identity, Alias}
ModifiedProperties : {Extensions, PoliciesIncluded, EmailAddressPolicyEnabled, PoliciesExcluded, RecipientTypeDetails,
                     RejectMessagesFrom, RecipientTypeDetailsValue, AcceptMessagesOnlyFromDLMembers, ArchiveName, UseDa
                     tabaseQuotaDefaults, OriginalPrimarySmtpAddress, ElcExpirationSuspensionEnabled, ServerLegacyDN, I
                     sMailboxEnabled, ReadOnlyPoliciesIncluded, IsValidSecurityPrincipal...}
Caller             : domain.local/Headquarters/Information Systems/Operations/Don Drieberg
Succeeded          : True
Error              : None
RunDate            : 1/26/2012 9:20:46 AM
OriginatingServer  : EXCH01 (14.01.0323.001)
Identity           : RgAAAACsFGTJn7mcTJ0+hnPZuWZoBwCmwLQTE/orS6kUJLJIy+JCAAAAkH9zAACmwLQTE/orS6kUJLJIy+JCAAAQcrvYAAAJ
IsValid            : True

From this, we can see that Cristin Broom's mailbox was created on 1/26 at 9:20 am by Don Drieberg.

The audit mailbox retains data for 90 days by default, and contains records of changes to all Exchange objects – mailboxes, distribution groups, contacts, connectors, inbox rules, etc. It doesn't log all of the details, though. For instance, although it logs mailbox changes, including which properties were changed, it doesn't include the value (before or after) of those properties. You just know that it was changed somehow. Still could be very handy for auditing. A simple command like this:

Search-AdminAuditLog -StartDate (get-date).adddays(-7) -EndDate (get-date) -Cmdlets new-distributiongroup | fl objectmodified, caller

Can show me any new distribution groups that were created in the past week:

ObjectModified : domain.local/Distribution Lists/CORP - IS-QA for Trade Hold
Caller         : domain.local /Headquarters/Information Systems/Operations/Don Drieberg

ObjectModified : domain.local/Ireland/Distribution Lists/Tax
Caller         : domain.local/Ireland/Users/IT/Admin. Accounts/Sarah Monet

If you don't supply a StartDate or EndDate, your query will return matches for the entire retention period (90 days, by default), which could be quite a lot of information.
If you don't supply a Cmdlets parameter, your query will return matches for all cmdlets.
Of course, you can always pipe the output through a Where-Object clause, to filter the results.

For more information about audit logging, see the Administrator Audit Logging section of the TechNet library.
- Mike


Friday, January 20, 2012

Quickly Retrieving Send-On-Behalf-Of Users


This morning, I needed to verify and provide a list of users with Send-On-Behalf-Of rights to a particular mailbox, and all the usual powershell methods showed the field, but ended with an ellipsis, so I couldn’t be certain that there weren’t more users than what I was seeing. I needed a quick way to view the complete list. After some playing around, I ended up with this nifty one-liner:

[PS]>foreach ($sender in (get-mailbox Mailbox2BeChecked).GrantSendOnBehalfTo) { $sender.tostring() }

This resulted in a nice, complete list of user DNs.

domain.local/Ireland/Users/IT/User1
domain.local/Ireland/Users/IT/User2
domain.local/Ireland/Users/IT/User3
domain.local/Ireland/Users/IT/User4


Thursday, January 12, 2012

Search For A Specific Folder

A recent snafu in our deployment of managed folders for email archiving resulted in duplicate folders in a few dozen mailboxes. I didn't know about the duplicate folders at the time it occurred, and none of the affected users reported the "extra" set of folders for over a month.

We use an Exchange managed folder mailbox policy to push a set of managed folders to each mailbox. When created by Exchange this way, the folders can't be modified by the user, which allows Enterprise Vault to apply a consistent archiving and retention policy to the contents of these folders.

If the Enterprise Vault (EV) provisioning process runs before the managed folders are created by Exchange, it causes two problems - (1) the EV-created folders are not managed by Exchange, which means that users can modify or even delete them, (2) and when Exchange tries to create the managed folders, it finds those folder names already exist, so Exchange creates a new set of folders with a slightly different name ("Managed Folders1"). The result is one set of folders targeted for archiving by EV, and another set of folders being managed by Exchange.

If we catch the problem early enough, before the user has moved any messages into either set of folders, then the fix is fairly easy.

  1. Open the mailbox in Outlook or OWA, and delete the Managed Folder hierarchy that was created by Enterprise Vault
  2. From an EMS prompt, remove the managed folder mailbox policy and folders.
        Set-Mailbox -Identity "mailboxID" -RemoveManagedFolderAndPolicy
  3. If the folders are empty, the previous command will delete the entire managed folder hierarchy. Then all we have to do is set the policy again.
        Set-Mailbox -Identity "mailboxID" -ManagedFolderMailboxPolicy
  4. And then run the assistant to actually push the new set of managed folders to the mailbox.
        Get-Mailbox -Identity "mailboxID" | Start-ManagedFolderAssistant
What does all that have to do with searching for a folder? Well, after fixing the reported mailbox, I was curious about how many others were out there that hadn't been reported. I needed to find every mailbox that had a "Managed Folders1" folder in it. Here's what I came up with.

$mbxs = Get-MailboxDatabase | Get-Mailbox -ResultSize unlimited
$y = @()
foreach ($mb in $mbxs)
{
    $x = Get-MailboxFolderStatistics $mb | where {$_.Name -match "Managed Folders*"} | Select Name
    $x | Add-Member -MemberType NoteProperty -Name "DisplayName" -Value $mb.DisplayName
    $y += $x
}
$y | where {$_ -AND $_.Name -eq "ManagedFolders1"} | sort DisplayName

It took a few minutes to run through our 3000+ mailboxes, but in the end, I discovered another 72 mailboxes that had Managed Folders that had been deployed incorrectly. Now, the time-consuming task of fixing them, as detailed above, begins. Bummer.