Mrjhide's Exchange and Random Musings

Removing Default Exchange 2016 Database

2016-02-03T17:56:00.000-08:00

I finally got around to working on my lab and getting the latest and greatest installed. The first order of business was to get current on Exchange and decommission both Exchange Server 2010 and 2013. Both of these uninstalled without a hitch.

After all the configurations were done it was time for a little clean up (mostly because I am a little neurotic with things like that). Namely getting rid of the first default database. No problem right? Well I hit a road block almost immediately after moving the archive and arbitration mailboxes getting the following error.

Now I will admit it didn't take long to find the solution but I did have to dig a little. Not having done 2016 up till this point and not reading too much on it (my own fault I know) I discovered one of the new items within 2016 is the Mailbox Audit logging mailbox. While this has been around since Exchange Server 2010 it was not contained in a system mailbox by default. More information can be found in the Exchange Server 2016 Technet article.

So running the Get Mailbox -Database "Default DB name" -auditlog | FL name,alias,servername,database command I was finally able to see where the problem was in deleting the mailbox database as can be seen in the following graphic.

Next up now was simply to move this last mailbox. This can be done with Get Mailbox -Database "Default DB name" -auditlog | New-MoveRequest -TargetDatabse "Database Name", once this was initiated I monitored the move request, with Get-MoveRequest and upon completion I removed the move request and was able to delete the mailbox.

Hopefully this will help someone trying to remove the default database.

P.S. As a side note rather than removing the database entirely it can be re-named and the path can be moved as well. This may be preferable for some administrators. Once the Database is re-named within the EAC, dis-mount the database and from the EMS run the following. Move-DatabasePath -Identity "DatabaseName" -EdbFilePath "path\DBname.edb" -LogFolderpath "path\logfolder"

What will Microsoft Professionals aspire to now?

2013-09-05T15:00:00.000-07:00

Microsoft on Friday August 30 2013 announced that it would be retiring the MCM, MCA and the MCSM programs. What the??? While I am not an MCM obtaining the MCM or MCSM for Exchange and/or Lync has been a long time goal for me as I am sure it has been for many other professionals out there. A copy of the email that was sent out announcing the retirement of these prestigious certifications can be found on Neil Johnson's Technet Blog.

What will the elite certification be now? Will MS try to revamp this or is this a sign of the movement to a devices/services organization that Microsoft is aspiring to be and will not require such elite professionals in the community? An open plea so to speak has been posted on the Microsoft Connect site by Jen Stirrup asking Microsoft not to get rid of these programs. The comments on this post are a definite indication that these are still a valued commodity.

In a reply to the plea and comments on the Microsoft Connect site Tim Sneath from Microsoft states that this was a long hard decision that took months to make, they evaluated things like how many people are certified, what is the recognition for these certs and the availability (US English only) and it came down to a simple fact that while it was a successful program for those that were in it the program itself was not enough. Tim went on to Further say that this is not a complete cancellation of an elite certification but a 'pause' to come up with something better. With the further explanation it does not sound as hopeless as the original letter t the current MCMs but you would think that it would have been phrased this way from the beginning not as an after thought after all the backlash.

I for one am hoping that in the wake of this announcement and the community uproar that Microsoft will be announcing (sooner rather than later) a new set of certifications or something along the lines of better that were so cryptically eluded to. Till then I will continue in my path to be better at what I do.

New Adventures

2013-03-01T10:22:00.000-08:00

I know I have promised in the past new post concerning all things Exchange/Lync/Office 365 and well you name it. Life has been a little hectic and that is really all I can say on that.

I have recently moved to the Seattle area for a new job, much of my duties will be very similar to what I have done in the past but with this change and the new environment my focus will be better and I will be much more dedicated to sharing my experiences here. Hopefully some of what I post will be of some value to the community as I think it is important for anyone in this business to help those around you.

That is all for now but I am looking forward to sharing more soon.

Removing OWA 2007 Logon options -

2008-11-05T09:37:00.000-08:00

A number of clients have been asking for customizations on the OWA 2007 logon page. There are a number of ways to customize the logon page the one I am going to focus on here dealing mainly with the option for a public logon vs. the private logon as seen here and removing the choice for using either a public or private computer.

There are several reasons why an administrator or IT department would want to change these default setting. First would be to increase security, removing the options at this point would default the logon to a public or shared computer logon. The effect of this would be that no username information is saved on a computer (good for shared or public machines) which would give a would be attacker half the information needed and the default timeout value is used incase the user forgets to logoff decreasing the chance someone else could use the session. The second reason to change this setting would be for convenience and decreasing help desk calls, by taking away the options the user does not have to be confused by what type of logon terminal is being used. For those networks that only allow internal access to OWA this can be made even more convenient by setting the logon page to automatically use a logon domain enabling users to just use their username rather than remembering domain\username.

With the default settings the user is given the option to choose a public or shared computer, or a private computer.

Choosing a public or shared computer will give the user a timeout period default of 15 minutes while choosing a private computer the default timeout value is 8 hours.

As noted above removing the options for choosing the type of terminal defaults the logon to public which would have the potential for aggravating some users that use OWA as their primary means for email. This can be remedied by setting the cookie timeout value for the public logon which will be addressed later in this article.

So to start the first thing to do to remove the logon options will be to modify logon.aspx files located in the Exchange directory at "x:\exchange_path\clientaccess\owa\auth\logon.aspx" A good practice before modifying this file would be to make a backup copy. To modify the file to remove the options the following code will have to be removed from the file. The easiest thing to do for this would be to look for the beginning and ending values.

<tr>

<td>

<col>

<col"w100">

<%=LocalizedStrings.GetHtmlEncoded(Strings.IDs.Security) %>

<%=(IsRtl ? "‏" : "‎") + LocalizedStrings.GetHtmlEncoded(Strings.IDs.OpenParentheses) %>

<%=LocalizedStrings.GetHtmlEncoded(Strings.IDs.ShowExplanation) %>

</a>

<%=LocalizedStrings.GetHtmlEncoded(Strings.IDs.HideExplanation) %>

</a>

<%=LocalizedStrings.GetHtmlEncoded(Strings.IDs.CloseParentheses) + (IsRtl ? "‏" : "‎") %>

</td>

</tr>

<tr>

</tr>

</tr>

<tr>

</tr>

</tr>

</tr>

</table>

</td>

</tr>

<tr><td><hr></td></tr>#

<table <%=tblStyle%>>#

<col>#

<col"w100">

<% if (!IsDownLevelClient) { %>

<tr>

</tr>

</tr>

<% } %>

<% else { %>

<tr>

</tr>

</tr>

<% } %>

</table>

The end result will give you the following logon screen.

Once this is accomplished it will have to be decided as to whether or not the default cookie timeout values are sufficient. If this is being done on a network that accesses OWA only internal and a user have to VPN in then the default values for the public cookie timeout should be modified. If it is going to be accessed from anywhere then the administrator or IT team should seriously consider keeping the default value.

Tune in soon for how to modify cookie timeout values for public and private computer logons.

Test email post

2008-06-02T16:37:00.001-07:00

This is definately an annoying first post but it had to be done. This is from my phone testing emailing in an update.