Wednesday, December 30, 2015

The User Profile Service service failed the logon. User Profile Cannot be Loaded.

One of my clients had a really strange issue the other day. He has a domain admin account in his domain and was not able to login to a server that I recently built. The server was an Exchange 2013 box, and was used in Coexistence mode to migrate his company from an Exchange 2007 box.
He was getting this error message when attempting to login:


This is a classic error message that I’m sure most technicians have seen before. Usually the resolution is to go into the registry and rename the user profile key to have a “.bak” extension and then do some other magic. However, this time, that was not the case. I looked in the registry and didn’t even see a reg key for his profile. I then looked in the c:\users folder and didn’t see a folder for his profile. Strange…

So what exactly was happening? Well, I took a look at the Event Viewer and found this error message:



I browsed to the file referenced in the error message and deleted it. Walla! He was able to login with his admin account. I’m not sure why this file was in the default user profile. It has something to do with Customer Experience Improvement Program:



The User Profile Service service failed the logon. User Profile Cannot be Loaded.

One of my clients had a really strange issue the other day. He has a domain admin account in his domain and was not able to login to a server that I recently built. The server was an Exchange 2013 box, and was used in Coexistence mode to migrate his company from an Exchange 2007 box.

He was getting this error message when attempting to login:

 


This is a classic error message that I’m sure most technicians have seen before. Usually the resolution is to go into the registry and rename the user profile key to have a “.bak” extension and then do some other magic. However, this time, that was not the case. I looked in the registry and didn’t even see a reg key for his profile. I then looked in the c:users folder and didn’t see a folder for his profile. Strange…


So what exactly was happening? Well, I took a look at the Event Viewer and found this error message:






I browsed to the file referenced in the error message and deleted it. Walla! He was able to login with his admin account. I’m not sure why this file was in the default user profile. It has something to do with Customer Experience Improvement Program:



 

Sunday, November 8, 2015

Office 365 Knowledge Base Library

Browsing Technet for instructional or troubleshooting articles can often be a task in itself. Here is a direct link to the Office 365 Knowledge Base Library on Technet:


This is a pretty clear method of finding the information you need when working with Office 365. 

Pin App Buttons to the Nav Bar in the 365 Admin Center

Just figured out I can pin app buttons to the nav bar in the Office 365 Admin center. Pretty cool!




Update: You can only have 3 buttons pinned at any one time. 

Office 365 Knowledge Base Library

Browsing Technet for instructional or troubleshooting articles can often be a task in itself. Here is a direct link to the Office 365 Knowledge Base Library on Technet:


This is a pretty clear method of finding the information you need when working with Office 365.

Pin App Buttons to the Nav Bar in the 365 Admin Center

Just figured out I can pin app buttons to the nav bar in the Office 365 Admin center. Pretty cool!






Update: You can only have 3 buttons pinned at any one time.

Thursday, October 15, 2015

Azure AD Connect Password Sync - Disabled and Grayed Out

Ran into a problem earlier with the new Azure AD Connect Wizard. We had configured the wizard and synced around 500 AD accounts. However, password sync was not working. I opened the wizard to confirm the configuration and found that “Password Hash Synchronization” was disabled. It was greyed out and could not be enabled.



I called Microsoft and worked for a couple hours with a technician to resolve the issue. Thought I should post the resolution here in case anyone else encounters this.
You can enable password sync by running the following script:

Import-Module ADSync
$adConnector = "<Local AD Connector Name>"
$aadConnector = “<Azure AD Connector Name>”
Set-ADSyncAADPasswordSyncState -ConnectorName $aadConnector –Enable $true
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $true
get-ADSyncAADPasswordSyncConfiguration -sourceconnector $adConnector



You need to set the value of the $adConnector and $aadConnector variables with the names of your Connectors found in the MIISClient.
Open the MIISClient by browsing to:


Right click on MIISClient.exe and click “Run As Administrator”.
You can obtain the names of your connectors in by going to the Connectors tab and looking at the Names column. There are two values here that you need to pay attention to. The Windows Azure Active Directory connector is your Azure Connector (obviously), and the other connector is your on-prem connector. 



Now that you have the names, just plug them into the script and run it. You can go back to the Azure AD Connect Wizard and verify that password sync is enabled. You can also go to the Event Viewer -> Application log and look for events 576 and 577. These two events are related to password sync and should show you all AD accounts that have successfully synced passwords.

You can force a sync by going to this location and running "DirectorySyncClientCmd.exe".


Azure AD Connect Password Sync - Disabled and Grayed Out

Ran into a problem earlier with the new Azure AD Connect Wizard. We had configured the wizard and synced around 500 AD accounts. However, password sync was not working. I opened the wizard to confirm the configuration and found that “Password Hash Synchronization” was disabled. It was greyed out and could not be enabled.





I called Microsoft and worked for a couple hours with a technician to resolve the issue. Thought I should post the resolution here in case anyone else encounters this.

You can enable password sync by running the following script:


Import-Module ADSync

$adConnector = "<Local AD Connector Name>"

$aadConnector = “<Azure AD Connector Name>”

Set-ADSyncAADPasswordSyncState -ConnectorName $aadConnector –Enable $true

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $true

get-ADSyncAADPasswordSyncConfiguration -sourceconnector $adConnector




You need to set the value of the $adConnector and $aadConnector variables with the names of your Connectors found in the MIISClient.

Open the MIISClient by browsing to:




Right click on MIISClient.exe and click “Run As Administrator”.

You can obtain the names of your connectors in by going to the Connectors tab and looking at the Names column. There are two values here that you need to pay attention to. The Windows Azure Active Directory connector is your Azure Connector (obviously), and the other connector is your on-prem connector.





Now that you have the names, just plug them into the script and run it. You can go back to the Azure AD Connect Wizard and verify that password sync is enabled. You can also go to the Event Viewer -> Application log and look for events 576 and 577. These two events are related to password sync and should show you all AD accounts that have successfully synced passwords.

You can force a sync by going to this location and running "DirectorySyncClientCmd.exe".



Monday, September 7, 2015

Finding All Mailboxes with a Forwarding Address in Exchange 2003


Believe it or not, the MSP I work for still has a client who is using Exchange 2003 as their primary email service. Despite several attempts at convincing them of the power of Office 365, they refuse to migrate. Last week the CFO contacted me and requested we provide them with a report of all users who have their email forwarded to another mailbox. “Ok, no problem.” I said helpfully as the client informed me of their request (at the time I didn’t even think about them having Exchange 2003…). I figured I would just connect to their server and do some quick PowerShell magic, and that would be it. Quick and painless, right? Wrong.

I did the RDP dance and got connected to their server, and my jaw just about hit the floor when I couldn’t find the Exchange Management Shell! I asked around the office to see if any of the other guys could help, but no one knew what to do. However, after talking with one of the guys, I remembered that this is Active Directory we are dealing with. There are objects, and those objects have attributes. The mailboxes/user accounts are objects, and those objects have attributes. So what attribute is it that controls forwarding addresses? I manually found one of the users who had a forwarding address configured. Then I opened up Active Directory Users and Computers, opened up her account properties, and went to the Attribute Editor tab. I filtered for attributes that have values and was able to see the email address that her mail was forwarding to. This was the “altRecipient” attribute.

I then did an “Advanced” search in Active Directory Users and Computers for any objects that have the “altRecipient” attribute configured, like so:





This search showed me all of the mailboxes that have an alternate recipient (forwarding address) configured. Not sure if there is another way to obtain this information, but this is the way that worked for me. Hopefully this article is able to help someone in the same situation. 

Finding All Mailboxes with a Forwarding Address in Exchange 2003


Believe it or not, the MSP I work for still has a client who is using Exchange 2003 as their primary email service. Despite several attempts at convincing them of the power of Office 365, they refuse to migrate. Last week the CFO contacted me and requested we provide them with a report of all users who have their email forwarded to another mailbox. “Ok, no problem.” I said helpfully as the client informed me of their request (at the time I didn’t even think about them having Exchange 2003…). I figured I would just connect to their server and do some quick PowerShell magic, and that would be it. Quick and painless, right? Wrong.



I did the RDP dance and got connected to their server, and my jaw just about hit the floor when I couldn’t find the Exchange Management Shell! I asked around the office to see if any of the other guys could help, but no one knew what to do. However, after talking with one of the guys, I remembered that this is Active Directory we are dealing with. There are objects, and those objects have attributes. The mailboxes/user accounts are objects, and those objects have attributes. So what attribute is it that controls forwarding addresses? I manually found one of the users who had a forwarding address configured. Then I opened up Active Directory Users and Computers, opened up her account properties, and went to the Attribute Editor tab. I filtered for attributes that have values and was able to see the email address that her mail was forwarding to. This was the “altRecipient” attribute.



I then did an “Advanced” search in Active Directory Users and Computers for any objects that have the “altRecipient” attribute configured, like so:




This search showed me all of the mailboxes that have an alternate recipient (forwarding address) configured. Not sure if there is another way to obtain this information, but this is the way that worked for me. Hopefully this article is able to help someone in the same situation.

Tuesday, September 1, 2015

Script for Querying All AD Computers' Time Source

This script will iterate through all computers in Active Directory and return the configured time server for each computer.

Wednesday, August 26, 2015

MSOnlineExtended Powershell Module

Something weird happened to me earlier. I was working on my O365 tenant with Powershell, and couldn’t remember the exact verbiage of a cmdlet that I needed. So, I did what any good sys admin would do; consulted the help! After clearing my Powershell console of many, angry looking red and yellow words (Powershell didn’t seem to be happy about me guessing at cmdlets), I ran “get-command *msol*”. Much to my surprise, I saw that many of the cmdlets were duplicated in the output:



What gives? Well, if you take a look at the column furthest to the right, you will see that there are two different Powershell modules being called; msonline and msonlineExtended. But why are there two modules? And what is the difference? I can’t find any explanation for this mystery module. It seems there are other people who are just as confused as me:



Do YOU know the purpose of the MSOnlineExtended module? If so, please leave a comment!

MSOnlineExtended Powershell Module

Something weird happened to me earlier. I was working on my O365 tenant with Powershell, and couldn’t remember the exact verbiage of a cmdlet that I needed. So, I did what any good sys admin would do; consulted the help! After clearing my Powershell console of many, angry looking red and yellow words (Powershell didn’t seem to be happy about me guessing at cmdlets), I ran “get-command *msol*”. Much to my surprise, I saw that many of the cmdlets were duplicated in the output:





What gives? Well, if you take a look at the column furthest to the right, you will see that there are two different Powershell modules being called; msonline and msonlineExtended. But why are there two modules? And what is the difference? I can’t find any explanation for this mystery module. It seems there are other people who are just as confused as me:




 
Do YOU know the purpose of the MSOnlineExtended module? If so, please leave a comment!

Thursday, August 13, 2015

Error When Reinstalling DirSync

Today is just not my day! After a failed attempt at installing/configuring DirSync, I removed it and tried to install and configure again. This time did not prove any more successful. I was getting this error midway through the install process:



I was able to figure this out after a little while and wanted to sure what I learned. If you are seeing this error message after removing DirSync and trying to reinstall, here’s what you need to do:

• Uninstall Windows Azure Active Directory Sync tool and reboot


• Remove this directory and all subfolders: C:\Program Files\Windows Azure Active Directory Sync 


• If you created a domain account to use for DirSync, remove it. Also remove the Office 365 account you created.
• Delete the Group accounts that the DirSync wizard created. Their names all begin with “FIM”


• Uninstall MSSQL
• Delete the MSSQL directory: C:\Program Files\Microsoft SQL Server\
• Reboot!
• You should be able to install and configure DirSync now.


Error When Reinstalling DirSync

Today is just not my day! After a failed attempt at installing/configuring DirSync, I removed it and tried to install and configure again. This time did not prove any more successful. I was getting this error midway through the install process:

I was able to figure this out after a little while and wanted to sure what I learned. If you are seeing this error message after removing DirSync and trying to reinstall, here’s what you need to do:

• Uninstall Windows Azure Active Directory Sync tool and reboot

• Remove this directory and all subfolders: C:Program FilesWindows Azure Active Directory Sync

• If you created a domain account to use for DirSync, remove it. Also remove the Office 365 account you created.
• Delete the Group accounts that the DirSync wizard created. Their names all begin with “FIM”

• Uninstall MSSQL
• Delete the MSSQL directory: C:Program FilesMicrosoft SQL Server
• Reboot!
• You should be able to install and configure DirSync now.

 

Wednesday, August 12, 2015

Failed to Mount Exchange 2010 Database

Recently, one of my users’ came to me and said he was missing two months worth of email. This was just after migrating to Exchange Online. We were using Exchange 2010 with System Center DPM for backups.


I restored the database that the users’ mailbox was on from a backup then copied it over to the Exchange server from the network share I restored it to. All was going well, until I tried to mount the darn thing.

I was getting this error and could not for the life of me decry-pt the meaning of it. There is obviously some type of IO issue/file not found. But what could it be?



I figured I’d better kick this one off with some basic troubleshooting. First, I checked the health of the database and made sure it was clean. Passed that test…


Then ran a repair on the database, to no avail.


After racking my brain for a good thirty minutes, and a few failed Google searches, I found the solution. It was so simple! I created the log file directory in the folder with the database, and voila, the database mounted without a single error!




I was able to see the ‘supposed’ location of the log file by opening the Exchange Management Shell and running the ‘Get-MailboxDatabase’ cmdlet, like so:
Get-MailBoxDatabase –Identity <Recovery DB Name> | FL Name, ServerName, EDBFilePath, LogFolderPath

                                           

I’m not sure why the database mounting process isn’t capable of creating the log file directory… I think Microsoft would have thought and planned for a situation like this. Hope this helps!

Failed to Mount Exchange 2010 Database

Recently, one of my users’ came to me and said he was missing two months worth of email. This was just after migrating to Exchange Online. We were using Exchange 2010 with System Center DPM for backups.
I restored the database that the users’ mailbox was on from a backup then copied it over to the Exchange server from the network share I restored it to. All was going well, until I tried to mount the darn thing.


I was getting this error and could not for the life of me decry-pt the meaning of it. There is obviously some type of IO issue/file not found. But what could it be?





I figured I’d better kick this one off with some basic troubleshooting. First, I checked the health of the database and made sure it was clean. Passed that test…




Then ran a repair on the database, to no avail.




After racking my brain for a good thirty minutes, and a few failed Google searches, I found the solution. It was so simple! I created the log file directory in the folder with the database, and voila, the database mounted without a single error!







I was able to see the ‘supposed’ location of the log file by opening the Exchange Management Shell and running the ‘Get-MailboxDatabase’ cmdlet, like so:

Get-MailBoxDatabase –Identity <Recovery DB Name> | FL Name, ServerName, EDBFilePath, LogFolderPath




 
I’m not sure why the database mounting process isn’t capable of creating the log file directory… I think Microsoft would have thought and planned for a situation like this. Hope this helps!

Sunday, March 8, 2015

Ping Sweeping with FPing

I generally use NMAP for any type of host discovery, but recently started experimenting with FPing. One thing I found is that, when performing a ping sweep, not only do I see the hosts that replied to the ping, but FPing also sends any unreachable IP addresses to stdout (which is super annoying and ugly if you ask me...).




Anyway, after a bit of research, I found a nifty way to suppress these messages. Linux allows us to redirect all error messages to /dev/null. So instead of just running the vanilla fping -a -g.... you would run the program and output all error messages /dev/null, like so:

Ping Sweeping with FPing

I generally use NMAP for any type of host discovery, but recently started experimenting with FPing. One thing I found is that, when performing a ping sweep, not only do I see the hosts that replied to the ping, but FPing also sends any unreachable IP addresses to stdout (which is super annoying and ugly if you ask me...).




Anyway, after a bit of research, I found a nifty way to suppress these messages. Linux allows us to redirect all error messages to /dev/null. So instead of just running the vanilla fping -a -g.... you would run the program and output all error messages /dev/null, like so:

Follow by Email

Search This Blog