Latest Entries »


I was a little bored this morning so i wrote this script as i am trying to learn powershell

it will give you a little menu system to check, stop & start lync services….

Hopefully it will help someone… and i might improve it Smile




set-executionpolicy unrestricted

$foreverloop = 4

Write-host "Thank you for using this little powershell script" -Backgroundcolor Black -Foregroundcolor Green
Write-host "Please repost and feel free to use!" -Backgroundcolor Black -Foregroundcolor Green
write-host "Always nice to hear feedback… Twitter @mccabej or email" -Backgroundcolor Black -Foregroundcolor Green


Write-host "Please Select 1 if you want to check the status of all Lync Services"
Write-host "Please Select 2 if you want to stop all services"
write-host "Please Select 3 if you want to start all services"
write-host "Press 0 to exit"
$menu = Read-host ("Enter your Selection and Press Enter")
$foreverloop = $menu


if ($menu -eq 1)

$service = get-service RTC*
Read-Host "Press Enter Key To Return To The Menu"
Elseif ($menu -eq 2)
    Foreach ($s in $service)
    if ($s.Status -eq "Running") {Stop-Service $s.Name -Force}

Read-host "Press Enter Key To Return To The Menu"
Elseif ($menu -eq 3)
    Foreach ($s in $service)
    if ($s.Status -eq "Stopped") {Start-Service $s.Name}
Read-host "Press Enter Key To Return To The Menu"

{Write-host "Exiting…."
Until ($foreverloop -eq 0)






We all have a network, every system we use runs on a network but yet it is something we often don’t think about in terms of data, sure you think of your wan links but now most people will put in 1GB switches and essentially fire and forget! Bringing Lync 2010 on to your network forces you to take a step back. The key thing with lync is to ensure a good user experience over anything else and while we can plan for servers and scale them appropriately people often forget about the network and what state that is in!

Before diving into to planning rates etc… I want to discuss of how robust certain things are in lync and why that although we do need to think and plan bandwidth etc… we have pretty resilient mechanisms with the media stack that’s built in to lync.

For Example

Our SIP implementation is done over TCP which is a reliable protocol and you have to wonder if the likes of QoS are required. App Sharing Also uses TCP.

We have an adaptive algorithm which monitors the available bandwidth on the channel and adjusts the codecs around to suit the channel and to give the best possible experience to the end user.

We also use FEC which can handle up to 10-15% (really ideal conditions) packet loss.

Video will adapt in terms of resolution and frames per second to the channel…

Finally as part of our resiliency of things worth noting is the fact we can suffer loss of the signalling channel and still maintain a call between endpoints! Its true.. it does limit functionality like putting the call on hold etc.. but the call itself will stay up and until one endpoint disconnects the media session will stay alive, but even better if the signalling channel comes up again the session will “repair” itself and continue on…..

Remember one of the main goals is to sustain voice so video will drop / app sharing will drop to keep the voice sessions alive.

One of the nice things I find in lync is the visual indicators of the network quality, this is a pre warning to the user to tell them they might suffer bad quality due to conditions that lync cannot control.

We also can use CAC which is controlled centrally and applies policies to the subnets and logical connection between points rather than a user. So a user can travel around and no matter where they are, they will only be affected by the correct CAC policy for that particular site which proves to be very useful and easy to manage.

So knowing all this information

Lets take a look at some of the bandwidth requirements, please use the maximum rates were possible for planning if you think FEC might happen on your network plan for that.

Slides taken from Tech-Ed Content!




The above information is great for video and audio but what about app sharing I hear you saying well…

App sharing is bursty (very bad english!), as in it will use a very small amount of bandwidth most of the time but when you get a screen change or something like that it will require a large amount of bandwidth for a short time frame. So you need to understand that and measure it on your networks.

As mentioned we can use CAC to help control bandwidth, for those who don’t know what CAC is, CAC stands for Call Admission Control and what you can do is set minimums on links between sites so that if the bandwidth is not there that a session can’t be established instead of a session being established and the user has a bad experience.

If you want to use QoS to help control call flow think about what we said above about our media stack, sip uses TCP but our audio uses UDP so by all means Prioritize the Audio over the network but there is no real need to do it for SIP.

All in all you need to observe that the network is doing and have visibility, please run network monitors and bandwidth monitors and eliminate the bottle necks after you have used the planning tools to design and identify the links. Use the bandwidth calculator available to give you an idea as well of what you will need based on your ideal profile versus what you have deployed currently in your environment.

Understanding our technology and planning appropriately is the key to a successful lync implementation!

I am sitting at a training session this morning and the question came up about lync online and the recording being disabled all of a sudden. the answer wasnt clear so a little bit of research popped up this answer from microsoft support


it would seem there is legal problems and political issues across different regions…. hopefully they will be all sorted very soon and it turned back on as it is a very useful little feature!


This document is provide to help you install the debugging tools and to analyze a crash dump to provide root cause for a BSOD. The process is relatively simple to obtain the analyses but to fully interpret the values and data after execution may require a deeper knowledge of windows and understanding of the background services

Section 1: Procedure For Installation

1. Download debugging tools from here

2. Run the installer and click next


3. Accept the license and click next


4. Accept the default install path and click next


5. Accept the default installation options and click next


6. Click Next to begin the install


7. Click Finish to complete the installation


Section 2: Procedure to Anaylze A Dump File

1. Click Start àAll Programs à Debugging Tools For Windows (x64) à Winbdg


2. Once the windows debugger opens click file à symbol path

3. Fill in the field with the following to use the current symbols online and click ok

NOTE: Debug Symbols Location for download


4. Now click open crash dump and browse to where you have your dump located

5. Click Yes to save information in this workspace


6. Allow Windbg to analyze the file and observe the output

7. As you will notice under bug analysis it will give you the faulting file in this case it was ntkrnlmp.exe, but this is not the root cause ….


8. Now in the field at the bottom of the screen type !analyze –v to get verbose information on the fault.. see below


9. From this we can see there is a problem with SMCGUI.exe which is a Symantec antivirus application. The customer is advised to disk check the system, ensure the exclusions are configured correctly and ensure there is no errors in the Hardware logs.


this is more for reference but if you want to know what versions of exchange and office will work with and what functionality it will have check the technet link below!


This was an interesting process to me and after years of working in IT you forget about how much actually happens behind the screens… and when you sitting there watching loading profile etc..

So first of all sometimes it can be very easy check the basics….

1. check the network and ensure there is nothing going on

2. check your domain controller ensure that is not over loaded and is processing requests quickly

3. check the machine you are on and see if it is slow anyway over all….


these are all fairly standard stuff to check… task manager will help you understand if your system is performing badly, if you are more advanced the perfmon and if you want to get more advanced well.. Smile

First thing you need to do is start here –>

This will show you how to turn on USERENV logging and how to read the file…

This is a great place to start… you can examine the trace and figure out what parts are taking ages…

a quick tip is in the userenv.log that will be created search for a string of lpuser

lpuser signifies a logon attempt … trace the log down from there until you see that the group policies applied successfully… this will give you great insight into the log on process…

after this you need to look at the file from the point of the group policies applying successfull to the point of explorer.exe (this is when they should see the desktop) and work thru the log at see what parts are taking alot of time to launch and run…


Additionally if you are like to get even more detail… download sysinternals suite and run procmon…

Click options and boot logging in procmon and reboot the machine and repeat the process…

this will give you another wealth of information that you can match up with the userenv log and see what process is possible causing the system to be slow

if it doesnt turn out to be any of this… then very simply using netmon or wireshark… on a laptop … plug the affected PC and the laptop into a hub and then the hub into the wall port or switch (sometimes you might need a network cable) and capture the trace of the the machine logging… what the streams and focus on any major delays in a response for different parts of the logon process…


this is not easy stuff sometime and can require a lot of time to troubleshoot but you will really begin to understand the depth of whats goes on during that little process…

I came across this one which i taught was very interesting….


basically an app logs on and uses a sql express database for whatever reason… well lets say the user leaves their desk and returns 15 minutes later… which is a common enough experience. They log back on to the app and they notice a timeout on the app or very slow to initially respond.


well this could be cause be sql express after about 10 mins it will close database connections and flush its cache…. if you want dont want this problem your app has to be programmed to work in the background to query a db every couple of minutes, doesnt have to do anything specific but just run a simply read query against the database… and then should fix it!

interesting little problems…

i am taking a longer break than expected from blogging etc.. but will return in a few weeks… try to get a handle on my new job!

Just released the updated SCOM management pack for Exchange 2010 SP1

its got a ton of new stuff in it so Download it here

interesting little problem and very easy resolution Smile

when installing lync on to windows 2008 r2 sp1 it will failed ! arghh i here you say

the failure is around the windows media framework for 2008 r2

the fix is simple!

installed the desktop experience feature and hey presto! all is good….