BLOG

Projects Currently Underway for 2015

NetApp install and configuration.

Create and install new 2012 domain

Migrate data from HP Lefthand Network storage to NetApp and new domain

Create users and shares on new storage. Create better security checkpoints

Forklift install of Avaya Phone switch including Audix.

VECC documentation Wiki/Knowledge base portal  redo.

Cad2Cad connection to Utah Highway Patrol.  Configure microwave network and add associated connections.

Move Database Path Error: WMI exception occurred on server – Quota violation

Over the past couple of days we have been installing a NetAPP SAN storage solution. Its up and configured and ready for data.  I am beginning to move data from our HP LeftHandnetwork storage.  Our Microsoft Exchange database has filled its LUN on the HP and needs moving pronto.

While trying to run the Move Database Path from inside Exchange Management Console I ran into an error at about 9 minutes into the move.

Failed to connect to target server "ExchangeServer". Error: WMI exception 
occured on server 'ExchangeServer.domain.local': Quota violation

I tried it again wondering if it was just a fluke. I tried it in powershell. No luck same error.

This install of Exchange and its database is not quite a year old and we had a size of 250 GB database. After searching through Microsoft;s Technet and Googling like a wild man, I came across others who had experienced the same problem. It turns out that this error is a feature of having to many transaction logs. Sure enough we had too many transaction logs.

There are three methods you can use to have Exchange clean up your unruly transaction logs.

1. You can copy everything manually and re-point. This seemed to be too much work and the internet reaction on success was mixed at best. Not a good solution in my opinion.

2. Do a backup using Microsoft Server Back Up Utility. It’s easy and straight forward but a tad time consuming.

or

3. Enable circular logging and remount the database. This was the option I took and it was quick and easy. It took less than 3 minutes and was successful. You must dismount and mount the database.

Mailbox-Database-Properties

How to Enable Circular Logging Through Exchange Management Console (EMC)
  1. Under Organization Configuration click on Mailbox;
  2. Click on Database Management where you find Databases;
  3. Take properties by right click and under meiantenance tab apply check of Enable circular logging.

Or

By Using PowerShell

Set-MailboxDatabase -CircularloggingEnabled:$true

Be sure to remember to re-disable it when done.

Set-MailboxDatabase -CircularloggingEnabled:$false

The Information Store must be restarted for either of these changes to take place!

Exchange 2010 Rules Quota Size Limit & How to Increase the Size

Today one of my Outlook power users received an error while trying to add a spam rule filter. The error was…

“One or more rules could not be uploaded to Exchange server and have been deactivated. This could be because some of the parameters are not supported or there is insufficient space to store all of your rules.”

It turns out that Exchange has a rule for the size of mailbox rules.

The rules size limit for mailboxes in Exchange Server 2007 (and later) has a default size of 64 KB per mailbox. The total rules size limit is also customizable limit up to 256 KB per mailbox.

More Information: http://support.microsoft.com/kb/886616/en-us

Exchange 2010 rulesquota size limit and how to increase it.

By default Exchange 2007 / 2010 rule size is 64 KB but is expandable to 256 KB.

How to Check the Size:

Get-Mailbox name@domain.com | fl rulesquota
RulesQuota : 64 KB (65,536 bytes)

It was 64KB. Increase it’s size to 256KB:

Set-Mailbox name@domain.com -rulesquota 256KB

Recheck New Size:

Get-Mailbox name@domain.com | fl rulesquota
RulesQuota : 256 KB (262,144 bytes)

It Can Be Set for All Users as well:

get-mailbox|set-mailbox -rulesquota 256kb

Recheck Your Work

get-mailbox|ft rulesquota, alias

Exchange 2010 – Out-of-office Response (OOF) Won’t Turn Off?

Recently I had a user whose Out of Office Reply was stuck on.  I hadn’t encountered this and a simple Google search and the fix was allegedly as simple as choosing start, run, Outlook .exe  /cleanrules. This didn’t work so I did option 2 which was logging in to Online Web Access (A silly name that seems redundant) and turning off the auto responder.  It was fixed in a snap… until it resurfaced a day later.

Another odd feature of this bug was the fact that you couldn’t turn on/off the auto responder nor edit the auto responder via Outlook.

We are a Microsoft Exchange 2010 shop with users that use Outlook 2007 or for the majority OWA. Don’t Judge! It’s just part of the joys of being a grossly underfunded IT department.  It appears via more Googling that this is a common problem amongst users of Exchange 2010 and Outlook. There were a lot of web pages advertising they could fix my problem but the solutions were varied and many I didn’t feel comfortable using.

I pondered… Could I fix this using Powershell?

I bet I can.  In simple terms, Microsofts Powershell is a powerful command line utility that allows a system administrator to use simple commands, script command etc and give full access to local and remote computers including COM and WMI features. Microsoft’s TechNet website has complete documentation of available commands.

The first command I ran was Get-MailboxAutoreplyConfiguration username

Get-MailboxAutorreplyConfiguration

It shows the mailbox out of office responder, state enabled or disabled.

The next command I ran was Set-MailboxAutoreplyConfiguration username –AutoReplyState DISABLED

This command disables the auto responder.

I logged into Outlook and now I could edit and change the auto responder.

Fun Fact of the Day:

Why is “out-of-office” abbreviated “OOF” in Microsoft documentation?

Because originally it was called Out of Facility.

Collaboration Moves Utah Toward Next-Gen 911

This is an article in Emergency Management Magazine about the phone project I have been working on for the last three years and the project that I won Utah APCO’s Technician of the Year Award.

Collaboration Moves Utah Toward Next-Gen 911

When the technology in several of Utah’s 911 centers was nearing obsolescence simultaneously, three of the state’s public safety directors decided to get creative.

“We thought, why not work together?” said Tina Scarlet, executive director of the Weber County, Utah, Emergency Services District. “Why not implement a shared model that various public safety answering points could use and that would be more efficient?”

In November 2011, Scarlet and two others — former Salt Lake Valley Emergency Communications Center (VECC) Executive Director William Harry and Utah Department of Public Safety Dispatch Center Manager Chris Rueckert — submitted a request for information for a multi-node, IP-based 911 call-handling solution.

“We wanted a system with advanced call-routing capabilities that could give us greater efficiencies and ultimately cost less than our various on-premise solutions,” Scarlet said. “The upgrade to an Internet-based system would also allow us to spread 911 calls around so that no one center had to put off a call when it was too busy.”

Today, the Greater Wasatch Multi-Node Project is the first IP-capable 911 call delivery system in Utah.

Multi-Node Advantages

Once the trio decided to explore the new strategy, they compared their current vendor’s solution to alternatives offered by Intrado and CenturyLink. Both companies offered key features they desired, including an emergency service number-based ESInet for all 911 wireline and wireless call handling and routing.

“We decided on the Intrado solution because it would allow both servers to be up and operational at the same time,” said Kevin Rose, statewide interoperability coordinator for the Utah Department of Technology Services. “Redundancy was paramount.”

The IP-based Intrado VIPER call processing equipment provides quadruple redundancy at VECC and Weber County, as well as a common database for call routing and mapping systems that displays the caller’s location.

In January 2013, VECC, Weber Area 911 and the Utah Department of Public Safety/Salt Lake Communications Center went live on the new ESInet and the Greater Wasatch Multi-Node Project was officially launched.

“About that time, several of the other public safety answering points (PSAPs) became intrigued about the direction this was going,” said Mark Whetsel, technical services manager at VECC.

The original three partners realized that the new system would allow them to host much of the new technology at two centers — VECC and Weber Area Dispatch — and give other centers that got smaller upgrades access to the full system via the Internet. That would allow them to combine resources and share the cost of fully upgrading the two centers instead of spending the same amount of money on all of them, Rose said.

“As we heard of other agencies getting ready to switch out their equipment, we asked if they wanted to join. We liked the fact that it reduced costs, but it was also about the ability to back each other up,” Scarlet said. “We are all large entities, and with the capabilities of the system and the way we can have the roaming login, we felt it would be a good fit to have others join in. Before we knew it we were adding additional members.”

Today, the Greater Wasatch Multi-Node Project supports six state-level and local PSAPs covering four counties in Utah, including the Bountiful City Police Department, Greater Salt Lake Unified Police Department and Salt Lake City Police Department.

The Multi-Node Project has two servers, one in Weber County and one in Salt Lake VECC.

“The servers are synchronized images of each other connected with T1 circuits,” Whetsel said. “Because we have a major fault line that runs over half the state, we wanted to create a geo-diverse network that would enable redundancy and resiliency.”

Whetsel said that because Weber County is about 60 miles north of Salt Lake City, it was a logical place to put the second node.

“If a major earthquake should hit, the chances of both of those centers being affected simultaneously is relatively remote,” he said. “And with the multi-node system, if one server goes down, the second server can pick up without missing a beat.”

Collaboration among the partners also generates cost savings through shared resources and equipment.

“Anytime you have multiple PSAPs working together it is a huge benefit because we can share information, training, etc.,” Scarlet said.

The Multi-Node Project also enables “agent roaming,” which lets users share call-taking positions across different PSAPs during times of high-call volume.

“A 911 call taker or dispatcher can log into any shared workstation, at any location, and receive and dispatch emergency calls as if they were at their own PSAP,” Scarlet said. “This collaboration of individual PSAPs and sharing of resources is unprecedented in Utah.”

 

Challenges and Unknowns

Naturally, forging new ground also came with challenges.

“There were a lot of unknowns because this was the first time such a system has been done in Utah,” Scarlet said. “There was a lot of pressure to ensure it succeeded. We had a great deal of confidence in the vendors, but the pressure was there.”

Scarlet said the partners agreed early on that this was a long-term relationship and it was imperative they were all on the same page. The team put together memorandums of understanding to establish how all system components would work and formed a governance structure including representatives from each partner agency.

In all, the system took 18 months from initialization to launch. A significant portion of that time was spent establishing network facilities and formalizing contacts with vendors. The three original partners also stipulated that the new system must be cost neutral, which threw another wrench into the plan.

“We couldn’t put new equipment in and have it cost the agencies more than their current budgetary allotment for that service,” Whetsel said. “Trying to maintain cost neutrality and keeping within those fiscal boundaries with the new equipment coming in was a challenge.”

Once the system went live, with a staggered start for each partner, the new dispatcher interface took some adjustment as well.

“Trying to coordinate training was time consuming,” Whetsel said. “Because it was a new deployment in Utah, we had to work closely with support technicians on the ground. We are still trying to muddle through the governance structure. We put together a panel of representatives from all the respective agencies, and we meet at least monthly and discuss what’s going on, direction, etc. We are working on formalizing the group, but it’s still in its infancy.”

 

Looking Forward

In addition to its other advantages, the IP capability of the Greater Wasatch Multi-Node Project has set the foundation for other next-gen 911 data services and applications, such as text-to-911.

“We are looking to have text messaging available by May 2014,” Scarlet said. “We’re working on establishing best practices for that now. Also when someone calls 911 now, there is a database that provides coordination between the phone number and the location of the caller. It is old school and requires a lot of manipulation. So we are beginning the process of converting from that old-school way of handling the auto number and auto location to a format that is more dynamic and uses geospatial data as opposed to a flat file.”

With the goal of being better prepared for next-generation 911 within two years, Utah is also working toward a CAD-to-CAD system that would allow for the electronic exchange of information between 911 operators. Utah also hopes to expand the backbone of the new 911 system throughout the state.

“There has been some discussion about applying this model throughout the state — to other regional or shared systems, so it’s given us some different options to explore,” Rose said. “We’d like to see if this model could work in other areas of the state and look at different options for the future that could save the state money and provide us more flexibility.”

Scarlet said she’s not sure how many other PSAPs in the state might emulate the Multi-Node Project. “In terms of how many others would do combined systems, that will be up to the PSAPs,” Scarlet said. “But I have heard that other PSAPs are talking about doing something similar. Anytime you can maximize your support and interoperability, it makes sense operationally and it makes sense for the citizens.”

While the project was the first of its kind in Utah, it could help set the stage for future initiatives.

“This was definitely something new to the state of Utah, but we got a lot of support for it from the surrounding areas,” Rose said. “Because it was so new we had to do quite a bit of educating to get buy-in. It was an eye-opener, and I think it will possibly influence other types of projects in the state down the road.”

You may use or reference this story with attribution and a link to
http://www.emergencymgmt.com/safety/Utah-Next-Gen-911.html