[x14]

Originally Posted by rizenbone

I thought it was supposed to time out after 18 hours and revert to manual as well. Mine have been in the 503 status for roughly 36 hours now. The first 2 applied great, the next 5 all are nopw stuck at 503 saying the patch manager is running with no other status.

The patch status doesn't update. It seems to only report the initial status and that's it.

[hillrp]

Originally Posted by jibi

For those wanting to decrease the polling interval from 4 hours:

- Open regedit
- Go to HKEY_LOCAL_MACHINE\SOFTWARE\Research In Motion\BlackBerry Enterprise Server\BlackBerry IT Admin Server
- Create (or edit) the following DWORD Value: AppProvisioningPollInterval
- Set this to the number of minutes you want, so 30 for 30 minutes
- Restart the BlackBerry Policy Service (from Services)

* Disclaimer: There is probably a reason why this has NOT been posted just yet. It can crash your server if the interval is too low. Proceed with caution. If you have 400 devices to update, don't do them all at once with a low interval. Resources WILL be used. Do we need any more warnings? No? Good, just be careful when you apply this if you do.

Recommended Production: 120 to 240
Recommended Test (Non-Production): 30 to 60
Pretty-Much-Instant Setting: 5 (NOT recommended unless extremely temporary for one user in a non-Production environment)

I often use a 5 minute interval, even in my Production environment, when pushing out controlled tests. Typically, I run 60 minutes as the norm for Production when pushing to a large group of users, and I used 15 minutes when I pushed the DST patch (groups of 150 users at a time). I have been doing this for over a year and not crashed my server yet. However, my BES has 4-CPUs @ 3.6 GHz and 4 GB Memory, and I'm running 4.1.2/HF1 for Exchange. I have about 400 users. I watch the Task Manager Performance screen as I push a large number of users to ensure I don't have performance issues. For a quick check, look at the "Completed Poll For Missing Apps, elapsed time... " statement in your Policy Log to see how long it takes to complete a cycle. Of course, caution is always good when playing with the "Poll for Missing Apps" interval.

[Frank Castle]

Has anyone gotten this to work properly? I have a slew of devices to push this to and have held off as my test group only users with 8700 / 8100 are applying the patch fully. All flavours of 7290 get the patch from the BES but NEVER run!! .. This is very frustrating and the manual install *could* be a fail back but our desktop area has locked down the ability for normal users to install an active X control!

What are you other admins doing / planning? At the rate this is going we will not have 1500+ devices patched by March 11th.

[hillrp]

Originally Posted by ZeroKool

FYI. If anyone receives the following when looking at a user in the BES after patches have been pushed to the device:

Configuration Name: DST 2007
Status Check Time:
Configuration Status: Device state invalid

The Handheld is just off w/ dead battery or such. No biggie.

Yes, I have encountered the "Device state invalid" status with several users. It appears that the SQL Database doesn't match the Handheld in regards to the application software installed. In several instances, there were two versions of an application (Berry411) listed in the SyncDeviceMgmt table for a user. If you look at the "Data" column in the SyncDeviceMgmt table, and only compare the info between the <t2> and </t2> delimiters, you can usually find the Duplicate applications, which can be caused by two different versions of the application (i.e., Berry411 2.63 & Berry411 3.61). If you are comfortable working with the SQL database, you can remove the row(s) relating to the duplicate application, then do an "Update Configuration Check Status" from the BES Manager and the status of the device should return to a "Normal" status. There are some variations of this issue regarding the DST Patch that I'm still trying to work through. If you want more detail, feel free to send me email with your contact info.

[rizenbone]

Coincidence, a missing step or a way to expedite??

I pushed the patch to (2) 8100s on Monday morning.

I went to run dst2007query and check my BES after lunch and both devices reflected a successful path applied. I checked the devices themselves and dst2007 showed as applied successfuly. Neither device prompted nor needed a reboot. I know, because I had both devices in my hands. This was my test group and considering all went well I did this:

Monday just after lunch I deployed it to (4) 8100s and an 8700. BES showed the application status as up to date, the devices themselves said Patch Manger is running and dstquery showed a 0x43,503 error until about noon today. I had rebooted these devices 3 times before since Monday and nothing seemed to get them going. On a reboot I headed directly to the patch on the device and saw it change from "Patch Manager is running....contacting website" to just "Patch Manager is running....." .

Someone gave me a "shot in the dark process" to try that worked on 3 of the 8100s in the last 10 minutes now - these 3 were all stuck at the same status since Monday with multiple reboots.

Here is what I did:

1) Power off via red power off key
2) Power back on
3) Remove and replace battery to reboot

I then instantly went to the patch and immediately saw it go from "Patch Manager is running....contacting website" to "Patch Manager is running....downloading update" and to a complete status. Ran DST2007 Query and sure enough, reports as applied now.

So, not convinced I tried a second unit skipping steps 1 and/or 1 and 2. Nothing. Never moved to downloading update. I then did all three steps and right away, I saw results, it finished, I reran dst2007 query and it too reports applied.

I repeated for unit 3 - again, trying to not follow all three steps above and nothing I did worked. So, I did all three steps as above and for a third straight time, patched and reported as applied within minutes.

The next unit and 8700 are not in house so I don't know on those yet.

Just posting this shot in the dark in case it helps others. I'm not convinced its that 3 step process that's doing it - (step 2 seems to be key?) - but I'm 3 for 3 on it within minutes.

[Frank Castle]

After a L O N G wait fro T support to discuss this further (not that I was expecting anything new)

They wanted me to take some of the devices that are not working and remove the IPPP service book (desktop IPP) .. this forces the patch to run through the carrier internet.

The patch still isn't applied but it will runs every 15 mins. I will be doing a query later tonight.

[rpfeffer]

I bet T-support staff is swamped with this DST issue

[tgray]

Originally Posted by JRV

Two possible alternatives: Set proxy credentials in MDS Properties, in which case all users authenticate as the account you set in MDS.

How is this done? How long do you have to leave it configured like this?

Exchange 2000
BES 4.1

[rpfeffer]

I had several successful pushes last night. Trying 4 more this morning. Fingers are crossed. This morning's push group consists of an 8700c, 8100c, and two 7290's.

[noname]

Originally Posted by rpfeffer

I had several successful pushes last night. Trying 4 more this morning. Fingers are crossed. This morning's push group consists of an 8700c, 8100c, and two 7290's.

Excellent, rpfeffer. Can you share an excerpt of what your POLC log looks like for a successful wireless push of the patch?

[stuwhite]

Just when we thought we knew what was going on, MS, send this....

We very recently discovered that if you apply the Exchange DST 2007 CDO patch prior to running the Outlook Time Zone Update Tool or the Exchange Time Zone Update Tool, recurring meetings created in Outlook Web Access (OWA) will not be updated properly.

The updated recommended steps are to apply the OS patch to client and server machines, run the Exchange and/or Outlook Time Zone Update Tool(s), then apply the CDO patch to Exchange.

So you now have to CDO patch your Exch boxes after the calendar re-base, which of course means your BES is now even laster :->

Deep joy
Stu

[BSquared]

Originally Posted by thomas.fischer

Thank you but we´ve found the problem. It was a security problem. We have to add the BES Admin Account to the Host where the Shared Files are.

Cheers,

Thomas

Could you be a bit more specific as to how this solution worked in your environment. We generally have a similar problem with sending applications OTA and this error occurs when the system polls for missing applications on an 8700.

BSquared

[pej]

Originally Posted by hillrp

Yes, I have encountered the "Device state invalid" status with several users. ...
If you are comfortable working with the SQL database, you can remove the row(s) relating to the duplicate application, then do an "Update Configuration Check Status" from the BES Manager and the status of the device should return to a "Normal" status. There are some variations of this issue regarding the DST Patch that I'm still trying to work through. If you want more detail, feel free to send me email with your contact info.

How are you identifying the user in the SyncDeviceMgmt table? I'm not sure how to map the UserConfigId to the user's PIN.

[rizenbone]

Anyone running Exchange 5.5 with their BES and find any documention covering this?

Yep, I know its old - we are slated for update in May so need to accomodate until then.

Thanks

I have pushed the BLackberry patch to (6) 8100s and (1) 8700.

(2) 8100s succesful flawlessly
(3) 8100s successful with some odd gymnastics
(1) 8100 reports helper not installed
(1) 8700 gives a 0x87,0x88 error

[hillrp]

Originally Posted by pej

How are you identifying the user in the SyncDeviceMgmt table? I'm not sure how to map the UserConfigId to the user's PIN.

I used some basic SQL Queries...
To get the ID number from the UserConfig table by partial user name run this:
SELECT *
FROM UserConfig
WHERE (DisplayName LIKE '%hill%')

Then use this command and insert the ID from the previous query for the user you want to search for in the SyncDeviceMgmt table:
SELECT *
FROM SyncDeviceMgmt
WHERE (UserConfigId = '93') AND (Data LIKE '%Berry411%')

Or you can leave the "And (Data LIKE '%Berry411%') to get all of the entries for that user and then scan through the Data column to see what is installed on the Handheld. If you are comfortable with SQL, I'm sure you could use a Join to perform both queries in one pass.

[hillrp]

Originally Posted by hillrp

I used some basic SQL Queries...
To get the ID number from the UserConfig table by partial user name run this:
SELECT *
FROM UserConfig
WHERE (DisplayName LIKE '%hill%')

Then use this command and insert the ID from the previous query for the user you want to search for in the SyncDeviceMgmt table:
SELECT *
FROM SyncDeviceMgmt
WHERE (UserConfigId = '93') AND (Data LIKE '%Berry411%')

Or you can leave the "And (Data LIKE '%Berry411%') to get all of the entries for that user and then scan through the Data column to see what is installed on the Handheld. If you are comfortable with SQL, I'm sure you could use a Join to perform both queries in one pass.

Here is one query that performs both functions:
SELECT UserConfig.DisplayName AS Expr1, SyncDeviceMgmt.*
FROM SyncDeviceMgmt INNER JOIN
UserConfig ON SyncDeviceMgmt.UserConfigId = UserConfig.Id
WHERE (UserConfig.DisplayName LIKE '%hill, Richard%')

[rpfeffer]

Originally Posted by noname

Excellent, rpfeffer. Can you share an excerpt of what your POLC log looks like for a successful wireless push of the patch?

If you tell me where I can find it.

did you mean policy log?

[rpfeffer]

If we are upgrading our servers this evening, will users without the update on their device still have full functionality until we get the device update pushed?

[pej]

Thanks for the sql, hillrp.

Now the next error on the agenda...we are seeing the following messages in the POLC log when our software configuration pushes. It's hard to know what matches to which user. I can't find any reference to the errors in the KnowledgeBase. We have 6 users in "Error" status at the moment across a range of devices and OS versions.

Anyone else seeing these?

[30000] (02/22 13:15:55):{0x15F8} Either the vendor ID 0x64 or hardware ID 0x84000b03 is not supported.
[20000] (02/22 13:15:58):{0x15F8} Module aliases: 2 providers for 25 targets
[30000] (02/22 13:16:00):{0x15F8} Either the vendor ID 0x88 or hardware ID 0x84000b03 is not supported.

[20000] (02/22 13:16:13):{0x15F8} Found a memory cached PackageDB 275AFC98 for hardwareId 9c000503 and flashSize 32768.
[30000] (02/22 13:16:14):{0x15F8} Either the vendor ID 0x64 or hardware ID 0x84000d03 is not supported.

[30000] (02/22 13:16:48):{0x15F8} Either the vendor ID 0x64 or hardware ID 0x9c000503 is not supported.

[30000] (02/22 13:17:23):{0x15F8} Either the vendor ID 0x66 or hardware ID 0x84000d03 is not supported.

[30000] (02/22 13:17:31):{0x15F8} Either the vendor ID 0x66 or hardware ID 0x9c000503 is not supported.

[30000] (02/22 13:17:57):{0x15F8} Either the vendor ID 0xd6 or hardware ID 0x84000b03 is not supported.

[30000] (02/22 13:18:18):{0x15F8} Either the vendor ID 0xae or hardware ID 0x84000b03 is not supported.

Our DST2007Query results don't show any incompatible devices:

[20000] (02/22 14:19:40.448):{0xAB8} Summary of results:
[20000] (02/22 14:19:40.448):{0xAB8} Total number of users: 105
[20000] (02/22 14:19:40.448):{0xAB8} Total number of users requiring patch: 105
[20000] (02/22 14:19:40.448):{0xAB8} 39 upgraded
[20000] (02/22 14:19:40.448):{0xAB8} 66 not upgraded [6 errors]
[20000] (02/22 14:19:40.448):{0xAB8} (78 helper installed)
[20000] (02/22 14:19:40.448):{0xAB8} (27 helper not installed)
[20000] (02/22 14:19:40.448):{0xAB8} Total number of users not requiring patch: 0
[20000] (02/22 14:19:40.448):{0xAB8} 0 upgrade not required
[20000] (02/22 14:19:40.448):{0xAB8} 0 no device info
[20000] (02/22 14:19:40.448):{0xAB8} (0 helper installed)
[20000] (02/22 14:19:40.448):{0xAB8} (0 helper not installed)
[20000] (02/22 14:19:40.448):{0xAB8} Total number of users with unsupported device code: 0

[rpfeffer]

Originally Posted by rpfeffer

If we are upgrading our servers this evening, will users without the update on their device still have full functionality until we get the device update pushed?

I apologize for quoting myself, but I am getting nervous as the time to update our servers this evening draws near.

Our exchange and Blackberry servers are set to be updated this evening, but I wasn't planning on pushing out to devices until Monday. I realize that goes against the recommended order, but I assumed this whole time that all devices will work correctly despite not having the DST updates. I've started pushing the updates out gradually, but I am not at 100% yet. Is this assumption correct, or am I going to have users unable to use email on their Blackberrys when we update the CDO files on exchange and the bes?