Tuesday, December 29, 2015

Limitations on Transferring Conference Calls

A client recently reported that they were no longer able to transfer conference calls to their mobile phone. I invited them to a conference to test and I was able to, however upon performing a screen share session with them I confirmed that they were not able to. Upon logging into their environment with a test account I confirmed that the test account was also unable to transfer conference calls:


We then tested and we were able to transfer a call when it was a peer to peer session. This made me think that this has to be due to a conferencing or voice policy. I checked and found that there was no difference in the configuration between my configuration and the clients. I spent some time reproducing and looking at each of the client’s .UCCAPI logs thinking it was something that was being denied in the in-band-provisioning however nothing jumped out. 

I finally noticed that it was only allowing me to transfer the conference call to a mobile phone and not to any other user like it would in the peer-to-peer session. I immediately checked the Phones list on the client that was not working and all the fields were blank:



Upon configuring the client with a Mobile phone:



I was then able to transfer the conference call to my mobile:

Solution:


In order to transfer conference calls to another phone, the phone number must be associated with the user’s account either by one of the telephone fields in AD, or by configuring the number within the client itself. 

Monday, December 21, 2015

Skype for Business UI Transfer Call Bug

After working on an issue for about half of a year now and finally finding a workaround for it I wanted to share it with anyone else who might also be having the same issue. Currently there is a known bug within the Skype for Business UI that does not allow users to transfer calls to other phone numbers or voicemail listed on someone’s contact card.

For example, if I was to receive a call, and wanted to transfer the call directly to one of my co-worker’s voice mail, normally you would initiate a transfer, search for the recipient, and right click their name to get a list of alternate call options from their contact card:




 When you select Voice Mail or any other number listed the client does nothing. 


SOLUTION:

A workaround for this issue is to force the Lync 2013 UI for the user with a client policy. Then this functionality still works:




I currently have a Microsoft Premier ticket open and I will update this post once the fix has been published. 

UPDATE: This has been addressed with the February 2016 client CU:
https://support.microsoft.com/en-us/kb/3114732

Friday, December 11, 2015

Federating Lync 2010 Hybrid with Skype for Business Online

I had an interesting case today where a client who was running a Lync 2010 hybrid with O365 Skype for Business online reported that federated partners who were also using Skype for Business Online could not IM, call, screen share, or see presence.  My initial reaction was to check and see if they had configured their on-premises instance for federated domains to use the “sipfed.online.lync.com” proxy FQDN as both Phil Sharp  and our Tom Pacyk had blogged about issues with Lync 2013 when you have the domain configured as both an Edge Server and Hosted Provider. Sure enough they had a couple domains configured this way.  I used the following command to update all the domains to not specify sipfed.online.lync.com as a proxy fqdn:

Get-CsAllowedDomain | Where {$_.ProxyFqdn -eq "sipfed.online.lync.com"} | Set-CsAllowedDomain -ProxyFqdn $null

I forced replication and waited 15 minutes and re-tested, still no luck. I then pulled the client logs and noticed that my messages were resulting in a 504 Server Time-Out:



The entire message did not give me much to go on:



Server: IncomingFederation/6.0.0.0
ms-diagnostics: 1036;reason="Previous hop shared address space peer did not report diagnostic information";Domain="clientpartnerdomain.org";PeerServer="sipfed.online.lync.com";source="sip-na.clientdomain.com"
ms-edge-proxy-message-trust: ms-source-type=AuthorizedServer;ms-ep-fqdn=na1.clientdomain.com;ms-source-network=federation;ms-source-verified-user=verified

I then decided to collect SIP and S4 traces from the edge server while attempting to IM a user on S4B online, the trace at this point also did not provide much information other than that it was being routed correctly but that once it reached O365 it would just timeout:



At this point I felt that this had to be something with O365’s Skype for Business settings and not an issue with our client’s on premises configuration. So I checked the portal’s settings and they had configured “On only for allowed domains” and enabled “Let people use Skype for Business to communicate with Skype users outside your organization”.



So federation was enabled, however it was only for specific domains, so I added the clientpartnerdomain.org to the list of allowed domains (which was empty) and then waited 30 minutes and sure enough it worked!


SOLUTION:


Make sure that if you have a hybrid configuration that your on premises allowed domains, are also listed in your O365 tenant! 

Thursday, September 24, 2015

The Never Ending Call Forward

Recently I had a client that reported they had a user who went on vacation and had configured their call forwarding settings to forward all their calls to the office receptionist while they were out. When they returned they disabled call forwarding however all of their calls were still being forwarded to the receptionist. Now this is not the first time I have heard of this issue, so I began by first taking a look at their call forwarding settings using SEFAUtil as sometimes the client and the pool won't sync and it takes forcibly changing it via SEFAUtil to change the setting. I pulled the user's config however there was nothing set:


I then tried using Anthony Caragol's Call Forwarding Script just to double check and see if maybe SEFAUtil wasn't reporting something correctly but it reported the same thing:



I thought that this was odd, so I decided to reproduce the issue and pull a trace from the FE pool. Doing so I saw that the call rang the user, then was responded with a PRAC and the forwarding user's identity:


Looking at the closest traces yielded nothing so I decided to also trace from the SBA that the user was registered to. This showed that a Added P-Asserted-Identity from EPID ashirey@clientdomain.com was being sent. Meaning that an endpoint was causing the call forwarding. Now this also was not unheard of however I found it strange that her client was showing no call forwarding and it was and endpoint. So I asked the user to log off of her client and then wait 1 minute then sign back in an re-test. This also yielded the same behavior and same message in the trace. 

SOLUTION:
I was starting to run out of ideas and so I had one last thought, why not have the user that was receiving the forwarded calls also sign out. After having both users sign out and remain signed out for 5 minutes, then signing back in, the call forwarding was finally disabled. 

So when in doubt while troubleshooting call forwarding have all the users sign out that are involved.

Tuesday, September 22, 2015

Lesson Learned: Issues with Signature Algorithms

Over the weekend we had a client whose Exchange and Lync internally signed certificates expired. On Sunday I went through their entire deployment and replaced all of the certificates with new certs issued by their PKI. 

Monday morning, they reported that their Lync clients were working, however all of their phones were not able to sign in. I immediately realized I had not replaced the certificate on their F5 and did not have the management IP and credentials. The IT person who had this information was on a plane and would be out of pocket for a couple hours. Therefore, in order to avoid an extended outage I attempted to change DNS for the VIP, that I thought their phones (CX600) were using, to point directly to one of the FE’s and skip the F5. After making the change they reported that all of their phones were still down. We could not get logs from the phones, so I thought that this had to still be somehow connected with the F5 but could not be certain due to lack of logs.

I was able to obtain the information for the F5 from a colleague luckily and began the certificate replacement process however the F5 would NOT accept the certificate. I reached out to one of our MVP’s Jeff Guillet and we were still not able to get it to take the certificate. I then escalated to F5 support at which point we attempted to export and import the certificate in a multitude of different ways. We tried the certificate by itself, no extended properties, importing via text file, importing it via CLI nothing seemed to work. When we pulled a packet capture, we saw the client hello, however we did not see a server hello in response:

Running via CLI: tcpdump -n -i 0.0:nnn -s0 -w /var/tmp/1-1475239048.pcap host 192.168.2.22 or 192.168.2.47 –vvv
Output:




We than ran an OpenSSL command on the F5 that would dump the certificate information when an attempt to connect to the VIP was made, this resulted in no certificate being sent:

[admin@sac-f5-02:Active:Changes Pending] ~ # openssl s_client -connect 192.168.2.148:443:


At this point, we swapped the old expired certificate back and verified that we were able to obtain output with a certificate warning which we could and running the same command showed the old cert and chain:

[admin@sac-f5-02:Active:Changes Pending] ~ # openssl s_client -connect 192.168.2.148:443


We then attempted a couple other variations of importing and exporting the certificate. We enabled debug logging on the SSL components, and then dumped the SSL log to the CLI:

tmsh modify /sys db log.ssl.level value Debug
tailf /var/log/ltm |grep -i 'ssl'

However this resulted in nothing showing up, I verified that logging was working by hitting another one of the VIP’s and the connection showed up in the logs. We then attempted to reboot the passive F5, and failover to that unit once it came back online in an attempt at answering the age old question “Did you reboot?” however this also did not make a change. We once again tried a series of imports and exports on the unit just to make sure it wasn’t a combination of the reboot failover and importing. No luck.

We tried one other command that essentially makes a connection and then dumps the output of that connection:



At this point, our client had been without phones for a little more than half the day, we had already escalated at F5 and had three of their support engineers on the call. They sent out an all support announcement as we had stumped most of their support staff and engineering also was out of ideas. Finally someone got back to them and asked “What signature algorithm was being used?” We immediately pulled the certificate information from the F5:

openssl x509 -in /config/filestore/files_d/Common_d/certificate_d/\:Common\:Lync2013-Web-int-2015-V4.crt_51169_1  -noout -text


We responded to the individual who asked, who then brought it to our attention that F5 does not support the RSASSA-PSS algorithm. We were able to find a posting on F5’s support forums that described a similar output from another user when suing RSASSA-PSS:


We were wondering why this all of a sudden started occurring. We had recently migrated their PKI from a single Root/Issuing server to a two tier PKI however it was supposed to be a 1:1 migration and no settings/configuration was to be changed outside of making it two tiers. We decided to check a certificate issued by their old root/issuing CA:


Then looking at all the certificates issued by the new intermediate/issuing CA:


A quick search on the internet also showed that Adobe, Citrix, Cisco, Firefox, and VMWare all do not support this algorithm and/or have various issues with its use. Various blog posts and forum entries alluded to that you had to rebuilt your PKI if this was the case. At this point we thought that we had two options, purchase a 3rd party certificate for the F5 with just the pool name or bypass SSL on the F5. After informing the client they elected to go with a Godaddy certificate. After obtaining, installing and verifying that it worked, we asked the client to then test a phone. They reported back that the phones were still not able to sign in…. so we then pulled the DHCP options and lo and behold they were pointing to the FE pool directly and not the F5. So all of this work on the F5 while important, was not the root cause of the phone issue. I immediately thought well if all of these companies and their devices don’t support RSASS-PSS then maybe the phones don’t either. Sure enough the Polycom CX line of phones does NOT support it!

EDIT: I have also been informed that the VVX line running at least 5.3.1 also do not support RSASSA-PSS.

We knew at this point we were looking at having to change their PKI due to the fact that we needed a .local on their FE pool’s internal cert and could not obtain that from Godaddy. We opened a up a ticket with Microsoft PSS and while waiting on the call back started looking deeper into how the PKI was setup. We noticed that their root CA and Intermediate/Issuing CA both were using the sha1RSA signature algorithm and not the RSASSA-PSS:


We thought this was strange, why was the intermediate CA issuing certs with a different signature algorithm than what their own certs were using. We attempted cloning the web server template and selecting different Cryptography providers, however this also did not work. We did a bit more research and noticed that one of the common “resolutions” when rebuilding the PKI was that we needed to disable alternatesignaturealgorithm by setting its value in the registry to 0. So we decided because the root and intermediate CA’s were using sha1RSA why not just try disabling that on the intermediate. 

Solution:
We made the change using the following command followed by restarting the certificate service:

certutil -setreg csp\alternatesignaturealgorithm 0
net stop certsvc && net start certsvc

We then reissued the FE pool cert and lo and behold we finally had a certificate using an acceptable signature algorithm:



We immediately assigned the Lync FE pool to use this new cert and were able to confirm with the client that their phones were able to sign in!

Lesson Learned: Check your signature algorithm when migrating PKI’s and whatever you use check for compatibility!

A big thanks to Jeff Guillet, Rick Steele, and Scott Winslow for assisting in this effort!

Friday, August 14, 2015

Script: Pool Objects

After my issue this week with attempting to decommission a Lync 2013 pool due to a lingering object, I decided to write a simple script that takes the pool name that you are attempting to remove, and runs though all possible objects and outputs any missed that are still attached to the pool.

Download OrphanedObjects.ps1

I have tested and confirmed that this works on Lync 2013 and S4B. It does NOT work on Lync 2010, but if I get enough interest in a 2010 version I could modify it to work.

Searching for Orphaned Objects

Recently when decommissioning a Lync 2013 pool, I ran into an issue where it said that by publishing the topology and removing the pool I would orphan existing users, endpoints, or devices:




Consult your Skype for Business Server documentation to learn how to move or disable objects still homed on the pool. To find those objects, execute the following cmdLets: Get-CsUser, Get-CsExUmContact, Get-CsCommonAreaPhone, Get-CsAnalogDevice, Get-CsRgsWorkflow, Get-CsDialInConferencingAccessNumber, Get-CsAudioTestServiceApplication, Get-CsTrustedApplicationEndpoint, Get-CsPersistentChatEndpoint.

Now I knew there were more objects that could trigger the orphaned objects failure, so I also ran Get-CsConferenceDirectory, Get-CsTrustedApplication, Get-CsTrustedApplicationComputer, Get-CsTrustedApplicationEndpoint, Get-CsTrustedApplicationPool. The only result I got was aCsAudioTestServiceApplication: 



I attempted to remove this however there is no remove cmdlet, and there is no option to set it's registrar pool with Set-CsAudioTestServiceApplication. 

I confirmed with one of my co-workers that it was not possible to remove this, however it should not be an object that prevents the removal of a pool. So what was causing the hold? 

Solution:
I decided to go into the weeds and dumped all user objects from AD to a CSV via CDSVE ( csvde -f test.csv -r objectClass=user ), and then searched for all users who had the msRTCSIP-PrimaryHomeServer value that matched the Lync 2013 server. Low and behold there was a Lync Room System object that was still homed to the Lync 2013 pool. After moving this object to the new S4B pool, I was then able to publish the topology.


Thursday, August 13, 2015

Lync 2013 to S4B CMS Migration Replication Issues

I recently moved the CMS from Lync 2013 to a new S4B pool for a project I was working on. I followed the normal procedure and re-ran bootstapper on all the nodes that make up the new pool hosting the CMS, as well as the old Lync 2013 pool to remove the CMS role. I verified that the S4B Master Replicator Agent and File Transfer Agent services were running on all four of the new S4B nodes. I rebooted all four of the new S4B servers individually and once complete I attempted to view the CMS replication status however it reported nothing was updating. All entries show UpToDate False, and all of them except the node I ran the Move-csManagmentServer cmdlet from and the edge servers show laststatusreport from around the time I performed the move:




I verified that I was able to download the Topology; I could see that FE01 was the ActiveMaster of the CMS:



I ran a trace using ManagmentCore scenario and saw a couple errors regarding the XDS-Replica folder:


This line stuck out particularly:

Query changes operation failed. Exception [System.UnauthorizedAccessException: Access to the path '\\S4BFENJ01.spscom.com\xds-replica\xds-master\xds-master\working\replication\tmp\0c112834-9f3e-49bc-ba01-fb0e4227e56e' is denied.

At this point I attempted to recreate the XDS-Replica folder by following Ken’s blog http://ucken.blogspot.com/2012/04/resetting-lync-cms-replication.htm ) however this didn’t seem to solve it. At this point I knew it had to be something to do with permissions/authentication. I checked and verified that all the servers in the new S4B pool were members of the RTCUniversalConfigReplicator group. 

Solution:
I finally enabled CAPI2 logs and saw that there was an expired certificate being passed. So I re-ran the deployment wizard, checked and sure enough the OAuth certificate had expired. Renewing the certificate and restarting each server propagated the OAuth certificate and replication began to work. 

Saturday, August 1, 2015

Exchange 2013 Cmdlets

I get asked often for various cmdlets on how to perform actions in Exchange PowerShell. So I have decided to post them on the blog. I will be updating this every time I find myself using a new one often so be sure to bookmark this page.


Export Mailbox folder sizes:
Get-Mailbox -Identity User | Get-MailboxFolderStatistics | Select Identity,FolderPath,FolderSize,ItemsInFolder | Sort-Object ItemsInFolder | fl | out-File C:\Temp\User-Mbox.txt

Export UPN of all users with an archive:
Get-Mailbox -Archive | Select-Object UserPrincipalName | Export-Csv -Path C:\Temp\AssignLicenseOptions.csv

Retrieve Message Tracking logs, sort by TotalBytes and save to txt file:
 Get-MessageTrackingLog -EventId SEND -Start "9/1/2011 06:00:00" -End "9/1/2011 20:00:00" -resultsize unlimited | Sort-Object TotalBytes -Descending | FT Sender, MessageSubject, TotalBytes > C:\test.txt

 Retrieve send-as permissions on a mailbox that is not the account tied to the mailbox:
 Get-Mailbox -Identity "ltemple" | Get-ADPermission | where { ($_.ExtendedRights -like "*Send-As*") -and -not ($_.User -like "NT AUTHORITY\SELF") } | select Identity, User, ExtendedRights, IsInherited | FT -Wrap

 Formatted List with Mailbox Size in Megabytes (MB) to CSV File:
Get-Mailbox | Get-MailboxStatistics | Select-Object DisplayName,{$_.TotalItemSize.Value.ToMB()} | export-csv -path C:\<FILENAME>.csv

Alternatively, you can specify the MBD also:
Get-MailboxDatabase -Identity "MailboxDatabase" | Get-Mailbox | Get-MailboxStatistics | Select-Object DisplayName,{$_.TotalItemSize.Value.ToMB()} | export-csv -path C:\Temp\MailboxSize.csv

Get Archive Size:
Get-Mailbox | Get-MailboxStatistics -Archive | Select-Object DisplayName,{$_.TotalItemSize.Value.ToMB()},Database | export-csv -path C:\Filename.csv

Formatted List with Mailbox Size in Megabytes (MB) Output to Screen:
Get-Mailbox | Get-MailboxStatistics | Format-Table DisplayName,{$_.TotalItemSize.Value.ToMB()} -auto

Get whitespace in DB's:
2010/2013:
Get-MailboxDatabase -Status | Select Servername, Name, AvailableNewMailboxSpace
2007:
Get-MailboxServer | Get-MailboxDatabase | Select Server, StorageGroupName, Name, @{Name="Size";expression={"{0:N2}" -f ((get-mailboxstatistics -database $_.Identity | Measure-Object -Property TotalItemSize,TotalDeletedItemSize -Sum |Select-Object Sum |Measure-Object -Property Sum -Sum).Sum.ToString() /1mb)}}

Get Mailbox Move Statistics: 
Get-MoveRequest | Get-MoveRequestStatistics | ft displayname,*stat*,perc*,totalmailboxsize

Only in Progress Moves:
Get-MoveRequest –MoveStatus InProgress | Get-MoveRequestStatistics | ft displayname,*stat*,perc*,totalmailboxsize

For a constant update:
while (1 -eq 1) { Get-MoveRequest | Get-MoveRequestStatistics; Start-Sleep -Seconds 2; Clear-Host; }

Empty Dumpster for User: 
search-mailbox -identity "MBauer" -searchdumpsterOnly -DeleteContent

Dump Message Tracking to GridView:
get-messagetrackinglog -Start "7/14/2015 8:00:00 AM" -End "7/14/2015 4:30:00 PM" -ResultSize Unlimited | select timestamp, ClientIp, ClientHostname, ServerIp, ServerHostname, ConnectorId, Source, EventId, InternalMessageId, Sender, {$_.Recipients}, {$_.RecipientStatus},MessageSubject, SourceContext, MessageId, TotalBytes, RecipientCount, RelatedRecipientAddress, Reference, ReturnPath, MessageInfo | Out-GridView

Dump Message Tracking Results to CSV: 
get-messagetrackinglog -MessageSubject "Test Message to Verify Tracking Details" -Start "1/26/2014 9:00:00 PM" -End "1/26/2014 9:30:00 PM" | select timestamp, ClientIp, ClientHostname, ServerIp, ServerHostname, SourceContext, ConnectorId, Source, EventId, InternalMessageId, MessageId, {$_.Recipients}, {$_.RecipientStatus}, TotalBytes, RecipientCount, RelatedRecipientAddress, Reference, MessageSubject, Sender, ReturnPath, MessageInfo | Export-Csv "c:\Temp\Track-results.csv"

Get Message Tracking for whole domain: 
get-messagetrackinglog -Server "Exchange-server-name" -Start "7/1/2010 11:34:00 AM" -End "8/10/2010 9:44:00 AM" -resultsize unlimited |where {$_.Sender -like "*@domain.org"}
  
Get Unified Messeging Extensions: 
Get-UMMailbox |ft name,extensions,UMDialPlan,UMMailboxPolicy
  
Get List of SMTP Addresses and export to CSV:
Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,PrimarySmtpAddress, @{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_.PrefixString -ceq “smtp”} | ForEach-Object {$_.SmtpAddress}}} | Export-CSV "C:\Temp\List-SMTP-Address.csv"

Get List ActiveSync Devices:
2013:
$Mailboxes = Get-Mailbox
$Mailboxes | ForEach {Get-MobileDeviceStatistics -Mailbox:$_.Identity} | Select Identity,DeviceType,DeviceUserAgent,DeviceID,LastSyncAttemptTime,LastSuccessSync | Export-CSV -Path C:\temp\ActiveSyncDevices.csv

2010:
Get-ActiveSyncDevice -ResultSize Unlimited | Select-Object UserDisplayName, Name, DeviceUserAgent | Export-Csv C:\Temp\ActiveSyncDevices.csv

Exch2007:
Get-Mailbox | ForEach {Get-ActiveSyncDeviceStatistics -Mailbox:$_.Identity} | ft DisplayName, Devicetype, DeviceUserAgent, LastSuccessSync

Get ActiveSync information for specific user:
Get-ActiveSyncDeviceStatistics -Mailbox blye | ft DeviceType, DeviceUserAgent, LastSuccessSync

Grant Rights to a user for a public folder and all sub-folders:
Get-PublicFolder –Identity “\IT” –Recurse | Add-PublicFolderClientPermission –User pponzeka –AccessRights PublishingEditor

See if anyone has sent or received email from a specific domain: 
Get-MessageTrackingLog -resultsize unlimited |where-object {$_.Recipients -like “*@renovatingla.com,*@bhkruper.com,*@usaveremodeling.com,*@rmogency.com” -AND $_.EventId -eq “Send”} |ft -auto >>C:\Temp\MailDomainSearch.txt

Batch move mailbox archives from text file:
$Mailboxes = Get-Content .\TextFile.txt
For ($Start = 0; $Start -lt $Mailboxes.length; $Start++) {New-MoveRequest –Identity `$Mailboxes[$Start] -ArchiveOnly -ArchiveTargetDatabase 'MailboxDatabaseName'}

Remove messages from queue with specific subject:
Remove-Message -Filter {Subject -eq "ENTERSUBJECT HERE"} -WithNDR $false
  
Export User's Contacts Folder:
New-MailboxExportRequest -Mailbox user1 -IncludeFolders “#Contacts#” -ExcludeDumpster -filepath \\server\share\user1.pst

Dump Mail Relay to txt file:
(Get-ReceiveConnector "exchange2007\allowedrelay").RemoteIPRanges | select Lowerbound,Upperbound,RangeFormat | sort-object Lowerbound| export-csv c:\rc.txt –NoTypeInformation

Move messages with a specific subject:
Get-Mailbox -Identity “MBauer” | Search-Mailbox -SearchQuery subject:”Alert: Host Parent Partition CPU Utilization high Resolution state: ”,from:”Honeypot@taskrepository.com” -TargetMailbox “MBauer” -TargetFolder “SCOM\CPU”

Update OAB:
Update-OfflineAddressBook “default offline address book”

Update DB Catalog Only (Re-Seed Content Index State_):
Update-MailboxDatabaseCopy "Mailboxes M-O\MailboxServer" -CatalogOnly

Set Domain on OWA/ECP Login Page:
Set-OwaVirtualDirectory ServerName\"owa (Default Web Site)" -LogonFormat Username -DefaultDomain TaskRepository

DL Auditing:
Get-DistributionGroup | Select-Object PrimarySMTPAddress | Sort-ObjectPrimarySMTPAddress | Export-CSV DL-ALL.csv -notype
Get-MessageTrackingLog -Server EXCH1 -EventId Expand -ResultSize Unlimited |Sort-Object RelatedRecipientAddress | Group-Object RelatedRecipientAddress |Sort-Object Name | Select-Object @{label="PrimarySmtpAddress";expression={$_.Name}}, Count | Export-CSV DL-Active.csv -notype
$file1 = Import-CSV -Path "DL-ALL.csv"
$file2 = Import-CSV -Path "DL-Active.csv"
Compare-Object $file1 $file2 -Property PrimarySmtpAddress -SyncWindow 500 |Sort-Object PrimarySmtpAddress | Select-Object -Property PrimarySmtpAddress |Export-Csv DL-Inactive.csv -NoType

Tracking Log Explorer:
Get-MessageTrackingLog -ResultSize Unlimited -Start "June 18 2015” | Out-GridView

Disable Calendar Repair:
Set-Mailbox -Identity username -Calendar Repair Disabled $True

Get all unhealthy Exchange resources:
$test = get-healthreport -server CATDALEXCH01 | where {$_.alertvalue -ne “healthy”}
foreach ($line in $test) {$line.entries | where {$_.alertvalue -ne “healthy”} | ft -auto}

Remove Automatic Mapping of Mailbox:
Remove-MailboxPermission -Identity celine -User ashley -AccessRights FullAccess

Add-MailboxPermission -Identity celine -User ashley -AccessRights FullAccess -AutoMapping:$false

Monday, April 13, 2015

​​Lessons Learned: Bug with Windows DNS Client

Last week I encountered an issue with what initially appeared to be a problem with DNS scavenging, but after hours of troubleshooting and research I was able to determine that it was actually a known issue with the Windows DNS client.

It all began on Monday when I spun up two new Windows Server 2012 servers, one physical and one VM, to be new domain controllers in our domain. I began testing on Wednesday, after replication had completed, to make sure that Directory Services and DNS BPA’s were clean. We were not receiving any alerts from System Center Operations Manager regarding any AD or DNS related issues. At that point I moved the Operations Master (FSMO) roles to the new servers and changed several system’s primary and secondary DNS to point to the new DC’s. By Thursday afternoon without any issues or alarms I began moving the rest of our servers to point to the new DC’s for primary and secondary DNS. 

The following afternoon, 24 hours later, I began to receive alarms and calls from our end users about various issues with Lync 2013, as well as an email from our developers reporting that they could not connect to the production database. I attempted to connect and was unable to. When I pinged the servers I received an IPv6 entry in return and not an IPv4 response as I had expected. When I attempted to force an IPv4 ping I received “hostname not found”. I jumped onto the new 2012 domain controller as well as one of the 2008 DC’s and immediately saw that DNS entries were missing.

At this point I thought DNS scavenging might have been enabled when I promoted the 2012 servers. I quickly checked and found that scavenging was enabled at the zone level but not at the server level. I could not figure out how or why the DNS entries were just disappearing on their own and began restoring one of the 2008 servers from the previous day using System Center Data Protection Manager 2012 so that I could have a list of all the entries before they started disappearing. After restoring and making the comparison I was able to determine that none of the static entries had been touched which again confirmed my theory that it was not scavenging as some entries were over 3 years old. I began to compare the list of entries and determined that only the 2008 and 2008 R2 servers had been affected. Our production Hyper-V cluster, Operations Manager, and Configuration Manager are all on 2012 and were still correctly published in DNS. I sent out an update to our infrastructure consulting group and Ryan Jackson replied with a KB he came across that stated there is an issue with the DNS client’s on:

Windows Vista
Windows Server 2008
Windows 7
Windows Server 2008 R2

Microsoft has identified and provided a hotfix and workaround for the issue:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2520155

Upon installing the hotfix and running ipconfig /registerdns the servers re-registered in DNS and have not disappeared since.

Saturday, February 14, 2015

Script: Office 365 Bulk Licensing

Recently I was asked to look into migrating some on-premise Exchange 2010 archives to Office 365.

In order to do so you must first license each user on Office 365 in order to migrate their archive. I had a fairly large number of users to license in Office 365 so I thought that there was bound to be a script out there to accomplish this. My searches took me to Roman Zarka’s blog however his script would not work if the user was not licensed. So I modified his script to ​check if the user was or was not licensed and then either license them or modify their current license.

The script assumes that you have already installed the Office 365 PowerShell Cmdlets as well as the Sign-In assistant.

Download O365BulkLicensing.ps1

References:

http://blogs.technet.com/b/zarkatech/archive/2012/12/05/bulk-enable-office-365-license-option.aspx 

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh124998.aspx