I’m writing with reference to a colleague’s blog post where he has found a very useful fix for a very annoying start up and log-on delay issue in Windows 7 SP1. Here’s his post, worth a read:
We were finding that computers in shared areas which had been logged on by many users (i.e. 50+ user profiles) were experiencing massive delays starting up and logging on. Until he found the fix the only solution was to leave the computers on all the time, or get them to start up really early in the morning.
One fix we tried was removing all the user profiles from the computers, and this only worked some of the time. Then my colleague found the right hot-fix and all of a sudden our startup and logon times dropped back to a few minutes. Big relief!
Here’s the relevant hotfix: http://support.microsoft.com/kb/2617858
See the blog entry (linked above) for a detailed explanation.
We recently started trying to configure the UM role in Exchange 2007 and had to buy an AudioCodes IP gateway to translate traffic from our legacy PBX into SIP traffic for the Exchange server.
Very early on we ran into an issue where we if we diverted a phone to the Exchange UM pilot number (i.e. re-direct all calls to voicemail) then if we called that phone we would get rejected.
A lot of diagnostics and tracing later, we discovered that the calls were being rejected by the UM server, and it was throwing a 1021 warning in the Application log. The message reads:
The Unified Messaging server rejected an incoming call with the ID “<call-ref-number>@<um-server-ip>”. Reason: “The Unified Messaging server cannot find a valid UM hunt group for “<extension>” associated with UM IP gateway “<um-server-ip>”.”
So the UM server was trying to find a hunt group for the extension that we were calling, and was thinking there wasn’t one configured. We did however have a hunt group configured! We had deleted the default hunt group on the ip gateway, and configured a new one with the pilot number as the pilot identifier…big mistake…
It turned out that when you configure a hunt group in UM, if you give it any Pilot Identifier number at all, that is the only number that it will be triggered for. So what you have to do is give it a blank Pilot Identifier! Trouble is you can’t do that, when you make a new hunt group the dialog will not let you create it without typing something in. So what do you do?
Well the answer is, delete and recreate the IP Gateway configuration object in the UM IP Gateways tab of the UM Organization Configuration section. That’s all you have to do! What happens is that when you create a new IP Gateway object it automatically creates a default hunt group with a blank pilot number – and that’s what we want.
Once you’ve done that you’ll be able to call the redirected phone and leave voicemail. Phew. Working UM system!
Lesson learned today: don’t configure things in UM if you don’t know what they’re for…
Got myself a new laptop recently with Vista preinstalled and when I installed Adobe Photoshop CS3 I found when I tried to exit the program it would always hang during the exit process. I’d never seen it do that before, but after searching the net I found I wasn’t alone – perhaps I had been lucky up to now.
Anyway after much messing about, reinstalling, trying various things (like turning off UAC and system restore before installing) I found a forum post from someone talking about the FLEXnet Licensing service and how it could be to blame for this stupid behaviour.
Some people said if the service was running it needed stopping and/or removing, others said if it was not running you should start it. Mine was set to manual but was running, so I was suspicious…if it’s manual then something has started it – therefore it must be needed. I wasn’t about to delete it then, and clearly it needed to run.
So I started searching for updates specifically for Macrovision FLEXnet – it is a 3rd party product after all. And low and behold I found a patch on Adobe’s site which nobody had mentioned – in this case for Adobe Acrobat 8 and 8.1. After installing the patch (which I believe replaced a dll) all was well again! Well done Macrovision and Adobe for making crap software.
Since finding the patch I did find a forum post which explains it as something to do with SATA drivers:
I recently put together a PKI and I decided it was time to experiment with certificates with subject alternative names (SANs) today. I immediately fell into an easy trap!
If you make a certificate with a SAN, you MUST have the address you use for the CN in the SAN field too. It seems if you have a SAN then ISA server will see this and only look for the DNS identity of the website it’s going to in the SAN field, instead of looking in the CN field too.
This leaves you with a “500 Internal Server Error – The target principal name is incorrect” error which is somewhat confusing!
So say you want a certificate that is valid for the following addresses:
What you must do is ensure you have the following field entries in your certificate:
In that way the CN is used as an identifier, and the san’s are used in the validity verification checks by ISA. Note however that IE and Firefox will still use the CN for validity checking as well.
One of my favourite things here at UWE is managing our ISA 2006 system, and this week I got bogged down with development websites being requested left, right and centre. To top it off they wanted their sites to have certificates too, and ISA server insists that you use one IP address per certificate. I knew about wildcard certificates (*.domain.com) but not actually tried them on ISA before, so I thought I’d solve my dev-problem with one.
Following the handy guidelines from isaserver.org, which are for ISA 2004 but still relevant for 2006, I created one listener with a wildcard certificate and rules for all the sites. Apparently one of the new things in ISA 2006 is the ability to use the wildcard certificate on the IIS site as well as on the ISA listener, but we’ll come back to that 🙂
After configuring I found http access would get to all the site just fine, ok that’s good. However when I tried https access I was always getting this error: “The network logon failed. (1790)“
Searching, I found a few people had seen this problem too but no-one seemed to have managed to solve it, save for a few. They chose to relax security and terminate SSL at the ISA server, and allowed the rules to connect back on port 80. That works but it’s not secure and I’ve seen link translation weirdness doing that in the past. So what’s the fix?
Well I found that if you put the wildcard certificate on the SITE as well as the listener, things start working. Just don’t ask me why! I think it’s probably an IIS thing, I’m just not sure. So don’t follow the guidelines ‘quite’ as explicitly and you’ll get there! And please let me know if this helps you or not, I’d love to know.
Found this helpful article today: Link translation causes an endless loop when you use Web servers that redirect HTTP requests as HTTPS requests in ISA Server 2006
We weren’t getting the endless loop because we were redirecting from http://website/ to https://website/path1 but ISA was still being a real pain in the gluteous maximus and changing the redirection link to http.
KB 841619 – when you can’t connect to SMS from an mmc console on a desktop
Here’s one that pisses me off royally, and another one that Microsoft seem unable to prove exists. At least there’s an answer though… Basically the scenario is: you give delegated access to SMS for a helpdesk user so they can provide remote assistance and diagnostics to users. You install the SMS console on their machine and when you connect and try to view the collections the egg-timer pops up, and you wait, and you wait, and then you get no collections! Zip, Nadda. Not a sausage. Eh!?
Well it seems to be caused by one things – XP Service Pack 2. The answer? Relax your security. Well done Microsoft…
Here’s the short of what to do to get around the problem:
1. Make sure the delegated user’s firewall is either off (if your in an Enterprise it probably will be off anyway) or make sure that tcp port 135 is open for your network, and %windir%system32wbemunsecapp.exe is added to the allowed applications list.
2. Run up dcomcnfg.exe, browse to “My Computer” in the console, choose properties of My Computer and choose the COM Security pane, and in the Access Permissions box click “Edit Limits…” and allow ANONYMOUS LOGON the Remote Access permission.
3. Now restart.
That should fix the issue. If it doesn’t then the user probably doesn’t have the right permissions in SMS, or the settings haven’t taken properly on the machine.
If you’re sure those settings taken then check that the user is a member of any groups that are in the “Distributed COM Users” local group on your SMS server/s.
Yet again, the usual annoyance with bloody Server 2003 SP1…argh!!! And now we have SP2 to play with too…what’s this one going to screw up I wonder…
If you’ve upgraded to 2003 SP1 on a server that has SMS2003, any delegated users that use the SMS console (e.g. for the remote control tools) will lose connectivity. See KB913000 article for assistance. It gets you to add a user or group to the ‘Distributed COM Users’ local group. God I should have known that one by now…
I found out a bit more about ‘why’ that makes it work and found the following article where you can give a security group remote launch and activation permissions.