By: Aaron Steele
Posted:
July 2, 2009 at 1:49 PMI ran into an issue today that I couldn’t initially explain. Windows Vista ® (post SP1) comes with a feature that builds XPS viewing through IE. While great, it seemed to be having problems on a users machine. The first clue to troubleshooting was that XPS had come to the user in a RMS protected email and knowing that XPS is a RMS aware application led me to trying to figure out why the built in XPS viewer that comes with Vista (the .Net 3.0 framework that is in the OS at least) can’t open an RMS protected document. I found that on Windows 7 this is not a problem, the IE integrated XPSViewer.exe is no longer in the OS, and only the stand-alone version exists, though oddly it is now just called XPSViewer in Windows 7. For Windows Vista the stand-alone version is a separate update that must be downloaded and installed. The link, while easily bingable, is http://www.microsoft.com/downloads/details.aspx?FamilyId=B8DCFFDD-E3A5-44CC-8021-7649FD37FFEE&displaylang=en. That will install the XPS Viewer EP to read XPS Documents. The one that came with Vista SP1 can’t open RMS protected XPS files, it gives an error that the application crashed and should be restarted. This error is embedded in the IE window that got spawned when the user tried to open the XPS document. The last change on the Windows Vista system that must be made is to change the default program for XPS file extensions to the XPS Viewer EP as opposed to XPSViewer.exe. When opening a RMS protected XPS file in the new viewer, the user is first prompted to chose the account with which to open the file 
After that selection, the document permissions are verified in the background and the file is opened with the rights granted to them by the sender of the email/document. I hope this helps you troubleshoot any RMS and XPS integration you may have.
By: Aaron Steele
Posted:
March 13, 2009 at 5:00 PMA wonderful thing has come to light. Microsoft has taken a burden away from the lowly IT Admin running the Virtual hosting environment for his company. How would you like the ability to, on a per user or per group basis, with a reasonable level of granularity, let users power on, power off, do minor configuration, even create their own guest Virtual machines. This is now a reality, and can be done through System Center Virtual Machine Manager and the Self Service web portal. On the face of it, you get a web site with ActiveX controls for remote control and the ability to assign ownership of existing machines to users or groups in your domain. When you dig down deep you also can setup templates for use in machine creation, you can assign specific VM hosts as the place users can create their own machines. You can prevent any new guest from hogging too much CPU or memory or disk, you can assign thresholds to the hosts to prevent the guests from taking the host down with them. It all begins with VMM itself. You setup and install SCVMM on a host, then you need to install the SCVMM web portal on a server with IIS. The end user web interface is nice, clean and simple. 
You see the list of VMs you are “owner” of, you can see the resources assigned to them, their status of on or off and the ability to control them. Within the Virtual Machine Manager Administrator Console you control the user roles defined on the system. This is where you get to define what can be done by which group of users. The default user group for the “Self-Service Portal” is Self Service Admins. Assign membership of this to your group of users, then you grant the ability to “globally” (depending on which machines they are end result “owners” of, they can perform the granted actions. On existing machines you control the actions that are able to be performed. 
For the creation of new machines you specify the templates available 
And you specify which VM hosts are available to store the resulting VM guests and the ISOs available to mount. 
I hope this has given you enough info to want to dig in and investigate more yourself.
By: Aaron Steele
Posted:
October 8, 2008 at 2:23 PMAs a colleague recently discovered, losing your cell phone to a thief is a disheartening experience. If you ever find yourself in this situation, and in this case have had your smart phone (including an iPhone) connected to your companies Microsoft Exchange Server 2007 system you can find small amounts of solace in its ability to help you manage said device. It should be noted that recent revisions of BlackBerry handhelds, even without a BlackBerry Enterprise Server in your environment, can configure their device to sync over the air through BlackBerry Internet Services. These type of connections are not detected nor can they be controlled in the same way as a Windows Mobile or iPhone Active Sync style Over The Air (OTA) Connection. Lost/Stolen BlackBerry devices should be wiped by contacting your cell phone provider. To manage and potentially remotely wipe your device you should 1. Sign onto your companies Exchange 2007 OWA interface and select Options from the top bar. 
2. Then select Mobile Devices from the menu on the left 
3. In there you will see the different mobile devices that are setup to sync with your account, their status and it will give you the ability to remove that device's ability to sync, Wipe All data from it, and display the recovery password setup for that device. If you have multiple devices setup to sync over the air, you can disable/delete them individually. 
4. If you select "Wipe All Data from Device..." you will get prompted with a confirmation dialog 
5. Selecting OK will initiate the wipe, and then you should remove the device from your device list. It is recommended to perform this wipe before you contact your service provider because as soon as your provider disconnects it from the network you can no longer wipe it with this service. As a note, your friendly neighborhood Exchange Administrator has the same abilities as you do in control of your device, the same rules apply. If you've canceled your service through your cell phone provider and disabled the device via their customer service, wiping the device in this way will have no impact. The device has be on the network and able to be contacted by the Exchange Server for the remote wipe to happen. Enjoy, and I hope you don't have the misfortune of needing to wipe your phone.
By: Aaron Steele
Posted:
August 13, 2008 at 10:59 AMIn a recent encounter at a client I discovered that it might be handy for Exchange Administrative and Support staff to be configured such that their Outlook settings do not access or download the OAB. This means that they will always be looking directly at the GAL for their addresses, and will be sure to have an updated view of what is there, not contingent on the System Attendent to create an OAB on it's schedule.
The load on Domain controllers does go up, as these persons are making direct LDAP lookups for every address, but for the limited scope I think it is benefitial.
Microsoft Outlook 2003 is the platform I've configured for this. There are a few ways that Outlook downloads the OAB and it is also dependent on if you are running Outlook in Cached mode or not.
If you are not in Cached Mode, you can simply go into the send/receive group for your exchange server and uncheck the box to download the Address Book when you send receive the group.
You may also want to get rid of the Send/Recieve menu item for downloading the Address Book. The registry key to do this is HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook\DisabledCmdBarItemsList and it is a string type key named TCID1 with a value set to 5658.
If you are running Outlook in cached mode it becomes slightly more complicated.
You have to create a few new registry keys as well as the work already done.
within the registry key
HKEY_CURRENT_USER\Software\Policies\Microsoft\Exchange\Exchange Provider create dword entries named:
Limit SRS Incremental Download
Limit Manual OAB Download
Limit SRS Full OAB Download
Allow SRS Full OAB Download
and set them all to dword:00000000.
Microsoft details these changes, as well as gives you some nice information about the OAB files and what they contain at the references below.
They also provide an as-is vbs script to make all the necessary registry changes.
References:
Hope this helps and helps your Service Desk staff in their quest to assist users.
By: Aaron Steele
Posted:
July 9, 2008 at 10:51 PMI ran into a 6 GB+ mailbox recently. And to boot, it had roughly 140,000 items in the inbox. Ponder that a little to yourself. What kind of impact do you think such a mailbox would have on your Exchange server? No matter how overbuilt it is, you'll notice that in terms of memory usage, disk usage, log file growth and undoubtedly other areas.
The next problem is, how do you deal with such a mailbox? If you try to interact with it, Outlook is bound to crash. Downloading said inbox into an OST would just kill a connection. Luckily for me OWA worked. It parsed the madness into 50 item chunks to view. Just deleting said items will generate a metric Ton of transaction logs, could crash your mailbox server if you aren't careful. I won't get into the process that was generating the mail, but leave it to be that said process would, if allowed, open each message and process then delete it. I would just have to configure permissions to allow said processing. The last thing about it would be that mail, if configured, would continue to flow into said mailbox, to be opened, processed and deleted.
Having discussions with some colleagues, it was suggested that we create a new storage group, on which we configure circular logging, and this mailbox would live in said SG. This solves the problem of transaction logs filing the drive and crashing the system and also enables a single DB that has to be managed in terms of grown and size and reclamation of unused space.
If we trust the process to remove content after processing, then we can forgo a mailbox policy to remove data after a period of time. If we don't trust the process, we must create and implement a managed folders policy on this mailbox.
A few things to mention:
- Exchange 2007 doesn't give you a graphical interface to see mailbox size across a server or even a storage group or for that matter a mailbox store. Many resource exist to find out what to do to get this data, but here is one I like, please watch line wrap and replace <server name> with your mailbox server.; 'Get-MailboxStatistics -server <servername>| Sort-Object TotalItemSize -Descending | ft DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount'
- When you do end up cleaning up this much mailbox data, be prepared to offline defragment the mailbox store that it used to be housed in. Microsoft reference for eseutil /d http://technet.microsoft.com/en-us/library/aa997972(EXCHG.80).aspx
- Be prepared to look at your exchange backup/archival solution and clean up any mess such a mailbox created.
I hope my knowledge helps you if you ever encounter such a mailbox.
|
|
|
|
 |
|
|
|
 ConsultantAaron Steele is a consultant for PointBridge. He has over 18 years of experience in the IT industry ranging from telecommunications design work, and work for higher education institutions including Ac... [more]
|
|
|
|
|
|