Just a quick note looking to see if anyone else is having the same problems that I've been having the last 24 hours.
I've had my 8125 about 3 weeks - and in that time have successfully upgraded to various summiter AKU2 ROMs. Last night my IT department pushed out a Goodlink policy update requiring passwords on all handhelds. Of course this is a pain in the ass, but I understand the issues and don't really have a problem with this policy.
However, there is a serious issue with the goodlink password requirement and AKU2 - basically they don't seem to work together. Immediately after having the policy pushed to me, the first time I did a soft reset I ended up with a blank white screen, with the task bar on top. The left side of the task bar would quickly flash "password" and then change to "Start" (w/ no start logo) and that was it... Nothing... Soft reset - same problem. The only thing that brought the device back was a hard reset, but once I reloaded goodlink and re-entered the password I was back in the same place.
After pulling my hair out for most of the night (it's not good to go to sleep at 3:00am when you have a client board meeting at 8:30am), I decided on my way to the airport that I would try loading the original Cingular ROM back. Surprise surprise, that worked (sort of - additional details below). After spending a lot of time trying out different solutions today, I've come to the conclusion that goodlink passwords only work with the original Cingular ROM - I don't know if it's a problem with AKU2 or a problem with the customizations.
Anyone else with this issue? I'm currently running goodlink 4.7, I'm wondering if 4.8 will fix any of these problems, I just can't find an OTA link for 4.8 and the cab from goodlink doesn't install correctly.
Additional problems - Even with the original ROM, there are some conflicts with the goodlink password. If I have certain shortcuts in the startup folder (at this point I think its AEBPlus and PQZII), the device freezes immediately after entering the password. After soft-resetting, I can explore the device from my PC while it's waiting for a password and delete the offending shortcuts, soft-reset again, and then I'm back in business.
I just posted the same problem earlier today. I have been using the latest Goodlink 4.8 build and have the same problem with AKU2. White screen of death with the status line showing at the top. My IT department turned off the password requirement for me. That seems the only way to fix it so far. I guess this is one reason Cingular has not released new firmware yet.
Ira
well - it's nice to know I'm not the only one.
Unfortunately my company doesn't officially support goodlink on an Windows Mobile devices - only the Treo 650. Given the fact that the device isn't supported AND I'm using a hacked ROM, I can just imagine the laughs they'll have at my expense.
At this point I'll just hang out and wait to see what happens.
I wonder if this is why Palm pulled the AKU2 update for the Treo 700w? Supposedly it was due to a compression issue, but who really knows? I'm posting a message on on treocentral, as there's a Good rep who monitors that board.
just curious.. does your it dept use the remote erase function on the backend?
i believe we do thus we do not require password protect on goodlink...
good to know i shouldn't have probs w/ it on the treo700w since i gotta setup one on fri..
seamonkey420 said:
just curious.. does your it dept use the remote erase function on the backend?
Click to expand...
Click to collapse
We do, but I work for a company that has become very, very, very conscious of protecting client data - with a couple of in-the-news issues (one moron left a cd with client employee data on a plane). They pushed the password requirement out to blackberries last week, and Goodlink devices this week.
Yes Ive had the same problem for last 2 weeks with both mini s and sp5 and goodlink.
Ive just updated goodlink to 4.8 and all seems to be fine.
Ive only just updated to 4.8 today but so far so good.
Update
I had some free time on my hands to tinker tonight - so I decided to see if I could test 4.8 with and AKU2 ROM.
Since my company hasn't rolled 4.8 out yet, I had to basically hack it in, which involved extracting the files from the 4.8 desktop installer from the goodlink website and copying those over my existing goodlink backup on the storage card (after copying the originals somewhere else of course).
I'm happy to report that, as of right now, the issue does seem to be resolved. It does look like 4.7 isn't compatible with AKU2 (if you use passwords) - so if this situation applies to you (on 4.7, using passwords) you shouldn't upgrade to an AKU2 ROM.
4.8 still does not work for me
I initially loaded goodlink 4.8 and had the password problem with the 2.17 rom. I have given up and am using the stock firmware until there is an official cingular update.
glad to hear others are having better luck.
ira
I had the same problem with GoodLink 4.7 and the new version 2.x ROMs on my Qtek 9100. I ended up downgrading to version 1.x ROMs (Button 1.5.4.2 WWE works fine with GoodLink 4.7.
aku2, goodlink 4.7/4.8, cingular 8125, and password policy
Thanks to CameronJ on his post. I was in the same boat, i.e. Going along fine on my Cingular 8125 with the released ROM when my company rolled out a password policy on Goodlink version 4.7. On the released ROM I started having unreliable service (disconnects almost continuously). I finally upgraded to AKU2 before seeing this thread (thanks Summiter for the great AKU2 build). However at that point I hit the consistent White Password Screen of Death as soon as I reinstalled my backup of Goodlink 4.7 and the policy was enforced.
However CameronJ's 4.8 suggestion was perfect. I too couldnt do a normal upgrade but by downloading 4.8 from Good and then copying the entire directory from the Pocket PC 2005/4.8/EN/ directory into my backup directory, I was back up and running with no problems. (this of course ignores all my false starts and problems). Dont use the Smartphone files as those wont work.
I was on the verge of giving up. Thanks for this thread.
additional password hacks
After playing around a bit in the registry the last week, I also found how to have a password that violates my organization's password policies. While I understand the reasoning behind having a password, the 30 minute timeout (which is the max my organization lets me set) is way too short. It looks like the goodlink password parameters work in the following way:
- Password policies are passed down through GoodLink and stored in the registry in HKEY_CURRENT_USER\ControlPanel\GoodLink\Password. There are a number of keys here, including ITLockedTime, ITLocked, ITPasswordMinLength, and a few others.
- When you go into the Lock/Password settings, the control panel settings dialog pulls from these registry keys to determine if your password meets policy.
- After a short period of time, any changes to these registry keys get overwritten back to corporate policy, however, nothing ever checks your password (as long as you don't go back into the Lock control panel extension) to make sure it complies with policy.
Basically, this means that you can change the key for minimum length or timeout and then go into the Lock control panel extension and change your password. I currently have a 1 character password set to timeout every 24 hours (instead of 6 characters that times out in 30 minutes). I've been running this way for about 4 days now, and even though the registry keys are back to policy, my reduced security password is still in force.
ITPasswordMinLength is self explanatory - change this to however many characters you want as your minimum.
ITLockedTime is a little more obscure. The decimal value here corresponds to the number of items in the list of timeout values in the timeout dropdown. 1 means only one item will show up (which is 0 minutes), I think 11 is 24 hours.
ITLocked - I'm guessing that if you set this to 0 it doesn't check these parameters at all, which means you might be able to disable the password. I haven't played with this one yet.
Re: additional password hacks
CameronJ said:
ITLocked - I'm guessing that if you set this to 0 it doesn't check these parameters at all, which means you might be able to disable the password. I haven't played with this one yet.
Click to expand...
Click to collapse
Wow, I've been looking for this kind of hack for awhile. I'm going mad with the couple minute forced timeout/lock policy I'm forced to live with. Imagine trying to use your pocket pc as a GPS device and it locking every couple minutes! (totally sucks)
Do you know if it's possible to do what did in a normal AKU2 MS Push Mail system? (I dont use goodlink, just regular microsoft push)
Which reg keys do I mess with?
How do you keep the changes from being detected/overwritten?
Thanks!
Any update on rather this has been addressed in a more recent ROM (AKU 2.3?). I am looking to start my company's Goodlink trial program and currently have 2.17. Thanks!
Re: additional password hacks
CameronJ said:
ITLocked - I'm guessing that if you set this to 0 it doesn't check these parameters at all, which means you might be able to disable the password. I haven't played with this one yet.
Click to expand...
Click to collapse
An update - this is the best way to go. Set ITLocked to 0, go into the password control panel applet and uncheck the password box. No more password requirement.
caiken said:
Any update on rather this has been addressed in a more recent ROM (AKU 2.3?). I am looking to start my company's Goodlink trial program and currently have 2.17. Thanks!
Click to expand...
Click to collapse
As long as you are using the most recent version of the goodlink client (4.8 ) you will be fine. The issue is with the previous version of the client (4.7).
I had no problem with this nasty password bug when I upgraded to AKU 2.3. I'm using Goodlink 4.8.
Ira
irablumberg said:
I had no problem with this nasty password bug when I upgraded to AKU 2.3. I'm using Goodlink 4.8.
Ira
Click to expand...
Click to collapse
This problem only exists with AKU2+ ROMs and GoodLink 4.7 - not 4.8
CameronJ said:
irablumberg said:
I had no problem with this nasty password bug when I upgraded to AKU 2.3. I'm using Goodlink 4.8.
Ira
Click to expand...
Click to collapse
This problem only exists with AKU2+ ROMs and GoodLink 4.7 - not 4.8
Click to expand...
Click to collapse
Thanks for the update guys. I'm assuming the "Get Good" link now downloads 4.8.
CameronJ,
You wrote:
An update - this is the best way to go. Set ITLocked to 0, go into the password control panel applet and uncheck the password box. No more password requirement.
Can you elaborate on this process? Where do I find the password control panel applet?
gaelen00 said:
CameronJ,
You wrote:
An update - this is the best way to go. Set ITLocked to 0, go into the password control panel applet and uncheck the password box. No more password requirement.
Can you elaborate on this process? Where do I find the password control panel applet?
Click to expand...
Click to collapse
Also, it appears that any changes that I make to the Good settings in the registry are over-written the very next time it syncs with the Good server. Anyone know how I can lock the registry settings that I set in addition to how I remove the requirement for the Good password controlled by my IT dept.
Hi all:
Just picked up my first WM device (Tilt) the other day. I'm have a problem turning off the password function on the device. I set it the other day and now it just getting to be a pain entering a password for wife any time she wants to use the phone.
Right now, the "Prompt if device used for" checkbox is greyed out so I cannot de-select it. the longest I can set the time limit for it one hour.
Thanks for any help,
Lost in Alabama
Sounds to me like you're connecting to an Exchange server that has this set as a policy, which shuts down your ability to turn it off. Are you syncing data with Exchange?
That's correct. I have since deleted my sync connection to my Exchange server at work.
thanks for any suggestions.
After some searching, looks like a way to remove the security policy would be to issue a remote wipe of my device from our Exchange Admin team. Would like avoid getting those admin guys involved if possible.
Maybe a hard reset? Seems drastic but that might be what's needed.
i did have the same problem, the only way is to hard reset your phone.
And then you wont be able to sync with the company server...
I would just petition them to increase the default time before the lock is applied.
(Having said that I have mine set to every five mins and thus have to enter the pin quite often- but I like the idea that its secure)
I have the same problem but i have set time after device wants password to 24 hours, so i never have to enter the password besides of booting up the device.
There is a program you can install that allows you to remove the security password policy on wm phones even while still synced with the exchange server. Zenyee.com Stay Unlock is the name of the program. I can't remember where to get it though. I just checked the Zenyee site and due to it's lack of a search feature I can't seem to find it again.
Found some other discussion on this elsewhere on the forums. Here is a link to a post by coderuckus talking about changing registry settings to circumvent the policy:
http://forum.xda-developers.com/showpost.php?p=1367367&postcount=1
going to fiddle with that later today and report back my findings.
I had the same problem - install the cab from the following thread and you'll be fine : http://forum.xda-developers.com/showthread.php?t=329570&highlight=Zenyee
Zerodivider said:
I had the same problem - install the cab from the following thread and you'll be fine : http://forum.xda-developers.com/showthread.php?t=329570&highlight=Zenyee
Click to expand...
Click to collapse
Jackpot! Thanks Zerodivider.
As info the directions from Coderuckus works to disable the security policy but it invalidates the sync'ability back to Exchange (at least in my case).
Directions below:
using a device registry editor (remote, or PHM) modify the following key(s)
The Exchange Security Policy (4131) updates the device policy:
HKLM\Security\Policies\00001023: 0 = Enabled; 1 = Disabled
Thanks for the help everybody!
Hello,
I would like to change the multiline-capabilites key in HKLM/System/State/Phone to '1' in order to make the menus necessary to control the line for outgoing calls appear. Since the changes will only take effect after reboot, I have to do so. However, after reboot, the menus still do not appear, but the registry key is changed back to '0'. I guess this is due to the simcard, which does not have a valid CSP-entry for ALS. Is there any possibility to make the phone not check the CSP but just keep the entry I set manually?
Thanks,
Chris
Any idea someone?
Shouldn't be to much of an issue (if you know how)?
I just want a registry entry not to change after reboot...
try to create reg script and put it in autorun or some small program in .net that executes silently and write changes to registry
CSP-override
Hello kulla,
kulla said:
try to create reg script and put it in autorun or some small program in .net that executes silently and write changes to registry
Click to expand...
Click to collapse
Thanks for your reply.
I'm not sure if your idea would do the trick, and I hardly doubt it.
I guess the registry entry is set as soon as the phone recognises the simcard.
At this point, the phone will either boot the Line2 capable taskbar and menus, or the regular menu, depending on this particular reg-key.
Therefore setting this key later in the boot-up procedure does probably not have any effect on the menu bar, as it would have been already loaded and configured when the reg-script would start.
I rather would like to somehow "protect" the reg-key from beeing altered by the phone during bootup.
There should be some way to prevent the phone from reading out the CSP from the simcard and writing it into the registry. I'm not sure if this is of any help - on Nokia phones, this feature (ignoring simcard/CSP) is called "CSP-override".
Maybe someone knows anything similar for Windows-Mobile?
Thanks,
Chris
Is there really nothing one can do to prevent windows from overriding the registry?
Is there really nothing one could can do to prevent windows from overriding the registry?
Unfortunately no. To the best of my knowledge, some ROMS are programmed to automatically revert to default registry values after a reboot.
Hi All,
Guess I have been spoiled with WinCE 2003 SE (4.21.1088 B15118.1.4) on my Motorola MPx220. On the MPx220, enabling the Phone Lock feature simultaneously locks the Keys and the Device. The Screen is remains 'viewable' so that one can look at upcoming appointments, time, etc. The Soft Button on the left of the screen displays 'Unlock' and when I press it, the Enter Password To Unlock screen appears where I enter my 4-digit Simple PIN.
On the HTC Fuze (aka TouchPro), the Key Lock and Password window appear to be separate. Selecting Key Lock simply locks the 'keys' but does not secure the device from access. The Password window does secure the device from access but until the device is unlocked, one cannot see the information on the Home screen ... note that I have the device configured to always return to the Home screen (aka Today).
I have tried several applications S2U2, SPB Mobile Shell, ThrottleLock, KeyLock, and TouchLockPro to name but a few. S2U2 & SPB Mobile Shell seem to be the closest to a solution but somehow, the Password screen manages to get on-top.
I would greatly appreciate any insight from seasoned experts.
Advance thanks,
-------------
ROM Version: 1.90.707.1 WWE
ROM Date : 08/01/08
Radio Version: 1.02.25.19
Protocol Version: 52.33.25.17U
I tried looking for that and so did many other people. Unfortunately, it's not possible. It's one of the differences between touchscreen and smartphone winmo.
Hi Kraize,
Appreciate the response; I'm going to do a Registry Dump of my MPx220 using PHM Regedit and an Registry Dump of the HTC. I have a utility that will allow me to compare results.
I expect *thousands* of differences but I will be looking specifically at the security/password related areas ... this should allow me to determine if it is .DLL specific.
Cheers,