Release : San Diego (7.0.318)
Could not load file or assembly SMTP.Net
Classification : Bug
Details
When an attempt is made to view a page in the eiPower Saver Solution the error below appears;
Server Error in '/Altiris/ei.PowerAgent' Application.
Configuration Error
Description:
An
error occurred during the processing of a configuration file required to
service this request. Please review the specific error details below and
modify your configuration file appropriately.
Parser Error Message: Could not load file or assembly 'SMTP.Net, Version=2.0.0.1, Culture=neutral, PublicKeyToken=986a9aa31056680b' or one of its dependencies. The system cannot find the file specified. Source Error:
Line 92: <add assembly="Infragistics.UltraChart.Render, Version=1.0.4001.78, Culture=neutral, PublicKeyToken=7DD5C3163F2CD0CB"/>
Line 93: <add assembly="Infragistics.UltraChart.Resources, Version=1.0.4001.78, Culture=neutral, PublicKeyToken=7DD5C3163F2CD0CB"/>
Line 94: <add assembly="SMTP.Net, Version=2.0.0.1, Culture=neutral, PublicKeyToken=986A9AA31056680B"/>
Line 95: <add assembly="Altiris.NS.UI.ControlsEx, Version=6.0.21.0, Culture=neutral, PublicKeyToken=D516CB311CFB6E4F"/>
Line 96: <add assembly="Altiris.Interop, Version=7.0.0.0, Culture=neutral, PublicKeyToken=D516CB311CFB6E4F"/>
|
Source File: C:\Program Files\Enterprise Infrastructure Partners\Power Saver\Web\web.config Line: 94
Assembly Load Trace: The following information can be helpful to determine why the assembly 'SMTP.Net, Version=2.0.0.1, Culture=neutral, PublicKeyToken=986a9aa31056680b' could not be loaded.
Workaround/Fix
The following line needs to be deleted from eiPower Saver Solution's web.config file. This file is found in directoryEnabling Event Replication
Classification : Bug
Details
When eiPower Saver Solution Sandi release (version 7.0.318) is installed the replication of power events is not enabled by default.Workaround/Fix
The file Enabled eiPower Event Replication - Sandi Update.sql contains a sql script that will enable event replication.Error when running Modelling report
Classification : Bug
Details
When the Modelling report is run the following error appears in the log :An unexpected SQL error occurred when running the RawSqlDataSource. ---> System.Data.SqlClient.SqlException: Violation of PRIMARY KEY constraint 'PK__#2E0F40F7__2F036530'. Cannot insert duplicate key in object 'dbo.@inactivity_periods'
Cause
This problem is caused by a bug in the stored procedure _ei_Energy_Consumption_Allocate_Events_To_Ranges which is used by the power modelling report.
Workaround/Fix
The file _ei_Energy_Consumption_Allocate_Events_To_Ranges - Auckland Hotfix.sql contains an updated version of this stored proc that fixes this problem.Release : Auckland (7.0.452)
Computers with Unknown Model names
Classification : Bug
Details
In Auckland a change was made to the way the Models Mapping Task creates and maps Computers to Models. Sometimes this can lead to large numbers of computers being assigned to a computer model named Unknown.Workaround/Fix
The following files contain updates to the stored procedures used by the Models Mapping Task and the Computer Missing Models report.- _ei_Computers_Updated_SystemName - Auckland Hotfix.sql
- spEiPowerGetUnmappedModels - Auckland Hotfix.sql
After running these sql scripts the number of computers mapped to an Unknown model with be reduced.
After running this SQL script file it is recommended that you go to the Models Wattage Assignment page and delete the existing Computer and Monitor Models. This will ensure that invalid Models are removed before the Models Mapping Task is re-run with the new stored procedure.
Status
Fixed in next versionCalculation error in Power Reports when the parameter KWH Consumption is set to Report Maximum
Classification : Bug
Details
Report shows incorrect results when Report Maximum is selected.
Workaround/Fix
The file _ei_Energy_Consumption_Allocate_Events_To_Ranges - Auckland Hotfix.sql
contains a updated stored procedure that corrects a problem in the Power Usage
calculations.
Status
Fixed in next version
New Report - Computers no Power Events last N hours
Classification :New Feature
Details
The file Computers no Power Events last N hours - Auckland.xml contains the
definition of a new report that can assist in trouble shouting computers that
are not reporting eiPower Saver events.
Go to the eiPower Saver reports in the NS
console and Import this XML file.
Error in Computers Running On Battery report
Classification : Bug
Details
There is a bug in the Computes Running on
Battery report that causes incorrect results to be displayed.
Workaround/Fix
The file Computers Running On Battery - Auckland
Hotfix.xml contains a new definition for this report that fixes this bug.
Status
Fixed in next versionRelease : Tokyo (7.1.825)
Error in Proof of Concept Report
Classification : Bug
Details
The POC
report contains a table called 'Averages (per computer per day)' that lists the
average daily per computer Cost, Energy and CO2 Emissions values for the
selected computers. The stored procedure used to generate this table has the
values for Cost ($) and Energy (KWH) swapped. Hence the values for Cost appear
in the row labeled Energy (KWH) and the values for Energy are in the row
labelled Cost ($).
Workaround/Fix
A new version
of the stored proc is available. The file Run the SQL statement contained in
the file _ei_Energy_Consumption_POC - Toyko Hotfix.sql on your Symantec_CMDB database to
update this proc.
Status
Fixed in next versionPermission issue with reports in eiPower dashboard.
Classification : Bug
Details
When the
eiPower Dashboard is opened some of the reports display the following error :
The permissions granted to user 'DOMAIN\USER' are
insufficient for performing this operation. (rsAccessDenied)
In some
installations the default permissions on the server job/task used for
performing RPO are insufficient to allow certain users to run these reports.
Workaround/Fix
First use
the following command to set the required permissions in the NS.
c:\Program Files\Altiris\Notification Server\bin\NScript.exe
SetPermissionsForGraphReports.cs
Set
permissions in the MS Reporting Server
- In IE, open the URL http://localhost/Reports
- Client the 'Show Details' buttom
- Click on the 'Edit' button for the eiPowerSaver folder
- Click on the security link
- Click on New Role Assignment
- In the 'Group or user name :' text box enter 'eiPower Data Entry'
- Check the Browser role checkbox.
- Click OK.
Status
Fixed in next versionError on RPO page.
Classification : Bug
Details
The following
error occurs when the RPO page is used :
Alternatively
the following error may be displayed or appear in the log file :
An error occured sending wakeup command.
The current user does not have required permission 'read' to load item
'0af7ad88-5b7d-4a3a-9384-9890d5185e78'
In some
installations the default permissions on the server job/task used for
performing RPO are insufficient to allow users in the eiPower Remote Power
Control group to read/execute these tasks.
Workaround/Fix
In order to
stop this error occurring it is necessary to give the eiPower Remote Power
Control security role permission to read and run the eiPower Remote
Computer Power On Job. This is done in the following way :
- In the Console navigate to Settings -> Security -> Roles
- In the Roles dropdown select the eiPower Remote Power Control
- In the View dropdown select All Items
- Click the Edit icon and in the Item Selector dialog check the Task -> Jobs and Tasks -> eiPower folder
- Click the Save Changes button
- On the Permissions page check the Read and Run Task checkboxes
- Click the Save Changes button.
Status
Fixed in next versioneiPower always installs to C:\program files and will not install to non standard location such as E:\apps
Classification : Bug (limitations in the SIM)
Details
When
solutions are installed from the SIM the user is not given the ability to
specify the installation directory for the solution. For Altirs solution this
is fine as they will always install under the directory where the SMP is
installed. For non Altiris solutions, such as eiPower this is not really an
option. Hence when eiPower (Tokyo version) is installed from the SIM it will
always install under the system directory.
eiPower will install successfully regardless of the location of the
There is no
way to change this behaviour which can cause a problem on servers where you
wish to install to a location other than the
system directory.
Workaround/Fix
In order to
install to a location other than the directory it
is necessary to do a manual installation of eiPower and to temporary change the
location of the directory prior to running the
installation.
See the
Manual Installation of eiPower section of this document
Status
Addressed in Adelaide Update 2.Manual Installation of eiPower (Tokyo version)
This section describes how to install eiPower manually to a directory other than the standard system directory.
1. Get the installation MSI file for eiPower (Tokyo version).
The installation file is named ei_PowerSaverSolution_7_1.msi
2. Check the version.
The Tokyo version of eiPower has the version number 7.1.825. This can be confirmed by right clicking on the MSI, going to the summary tab and clicking on the Comments field. The comments should read the following :
Enterprise Infrastructure Partners eiPower Saver Solution 7.1.825.0
3. Temporary change the location of the
The
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
Note: Record the existing value before changing so that you can change it back after the installation.
4. Run the install.
When not run from the SIM the following command line must be used to run the eiPower installer :
msiexec /i ei_PowerSaverSolution_7_1.msi skipaim=1
5. Restore the original
Set the [ProgramFileDir] registry value back to is original value.
It is important that this is done before the following steps as IIS needs to load files located under the
6. Restart IIS and Altiris services
When installed using the SIM the SIM takes care of these, however when installing manually we need to do them.
From the command line run the following :
- iisreset
- net stop AltirisReceiverService
- net stop AltirisClientMsgDispatcher
- net stop aexsvc
- net start aexsvc
- net start AltirisReceiverService
- net start AltirisClientMsgDispatcher
7. Check the solution is working
Open the Symantec Management Console and click on the eiPower pages
Release : Adelaide (7.1.1180)
Computer may not go into standby if there is no user logged into the computer.
Classification : Bug
Details
If the eiPowerAgentUI process is not running then the eiPower agent may not put the computer into Standby or Hibernate. This means that Scheduled Power Policy End Action = Standby\Hibernate will not work and Insomnia detection will not work.
Generally it is Windows that puts a computer into Stanby/Hibernate and the eiPower agent simply sets the Window's power schemes as required at the correct times. However there are 2 cases were the eiPower agent puts the computer into standby directly. This happens when the agent detects insomnia and when there is a Scheduled Power Policy with End Action = Standby\Hibernate. When this occurs it is the eiPower agent that puts the computer into standby/hibernate and not Windows.
Before putting the computer into standby/hibernate the eiPower agent displays a countdown dialog to the user to allow them to stop the computer going into standby. This countdown dialog is displayed to the user by the eiPowerAgentUI process. When this process is not running the eiPower agent is unable to display the countdown and will not put the computer into standby.
Generally it is Windows that puts a computer into Stanby/Hibernate and the eiPower agent simply sets the Window's power schemes as required at the correct times. However there are 2 cases were the eiPower agent puts the computer into standby directly. This happens when the agent detects insomnia and when there is a Scheduled Power Policy with End Action = Standby\Hibernate. When this occurs it is the eiPower agent that puts the computer into standby/hibernate and not Windows.
Before putting the computer into standby/hibernate the eiPower agent displays a countdown dialog to the user to allow them to stop the computer going into standby. This countdown dialog is displayed to the user by the eiPowerAgentUI process. When this process is not running the eiPower agent is unable to display the countdown and will not put the computer into standby.
The eiPowerAgentUI is launched by the eiPowerAgent service when a user logs into the computer. Hence when no user is logged in to the computer the eiPowerAgentUI is not running and the eiPower agent will not put the computer into standby.
Note : eiPower Agent does not support RDP users and hence the UI process will not be launched when a user logs into the computer via RDP.
Workaround/Fix
None.
Don't use scheduled power policies.
Don't use scheduled power policies.
Status
Fixed in next version
Offsite Flag flips for 60 seconds whenever agent policies are processed
Classification : Bug
Details
When the Offsite detection feature of eiPower is enabled the Offsite status of the computer can flip to Offsite for a 60 second period immediately after the eiPower agent processes updated policy Xml. This flipping of the Offsite flag appears as a 60 second power event for the computer where the Offsite flag is set to True.This short flipping of the Offsite flag has no negative impact on the operation of the agent and due to the short time period has no noticeable affect on the results of the eiPower reports. The only impact is that additional events are generated and this can have a performance impact when running the reports. Additionally these additional events will increase the size of the ei Power Events dataClass table (Inv_ei_PowerEvents). In some environments the additional number of events can also impact event replication performance in multi-tiered environments.
This problem only affects environments where the Offsite detection feature is enabled.
Workaround/Fix
A SQL script has been created to consolidate these short 'flip' events. This reduces the Inv_ei_PowerEvents table size and removes any negative impact these events have on the reports or on event replication
Status
Fixed in next versionDuplicate Scheduled Power Policies created after Hierarchy Replication
Classification : Bug
Details
When eiPower agent configuration policies are replicated from a Parent SMP to a child SMP any Scheduled or Application power policies that exist will be duplicated.Workaround/Fix
Manual deletion of the duplicate Schedule and Application power policies.
Status
Fixed in next versionLoss of Power Events when eiPower Agent is unable to communicate with Altiris Agent
Classification : Bug
Details
To sends power events to the SMP the eiPower agent service makes use of the Altiris Agent to store and forward these events to the SMP. When eiPower attempts to send its events but fails to communicate with the Altiris agent these events are lost. Generally this situation is very rare, however it can happen when the Altiris agent is shut down or is unresponsive.On the server these lost events appear as Unknowns or gaps in the power event data. Small periods of unknown are common and not a problem, however where there are large periods of unknown the accuracy of the reports will be affected.
Workaround/Fix
Where large periods of unknowns exists for a computer check that the Altiris agent is working correctly.Status
Fixed in next versionModel Wattage Assignment page fails when there is a large number of Models
Classification : ASP.NET default configuration
Note. This problem may affect any release of eiPower that have MS security update MS11-100
Details
When the list of Computer/Monitor models is very large the Model Wattage Assignment page stops working. Additionally the import of Model wattage data from CSV file also stops working.For very large lists of Models when the Save button is clicked the page generates the following error :
Unable
to save power figures. There are 132 rows with errors. Place your mouse over
these rows to see the error.
when your scroll down to the bottom of the list you will see a many rows where the Name and Wattage values textboxes are blank.
The problem happens because Microsoft introduced in security update MS11-100 to limit the
number of variables that can be submitted in a single HTTP POST
request. The default limit is now 500 which should be enough for normal web
applications, however when you have a large list of Models this limit will be exceeded.
Workaround/Fix
In order to increase the limit so that the page works for
a large number of models it is necessary to manually update your web.config
file.
To do this...
Go to the directory \Power Saver\Web
Open the web.config file and and go to the appSettings
section. Add the line shown in blue below
Release : Adelaide Update 2 (7.1.1395)
SWD Integration Wakeup tasks are not getting deleted when a SWD/Patch schedule is changed.
Classification : Bug
Details
When SWD or Patch Integration is selected by the administrator the eiPower agent creates wake-up tasks to wake the computer 5 minutes before any SWD or Patch task is scheduled to run. When the scheduled execution time for a SWD or Patch task is changed in the console the eiPower agent creates a wake-up for the new schedule but does not delete the wakeup task for the old schedule.
Hence the computer will continue to wake-up at the old scheduled time as well as waking up at the new scheduled time.
This will have no affect on the computer beyond the addition wake-up operations.
Workaround
Old wake-up tasks can be deleted by temporarily disabling SWD and Patch integration. This will cause the eiPower agent to delete all wake-up tasks. After all agents have received this change (depends on your Client Policy update interval - usually 4 hours) then the SWD/Patch integration can be re-enabled which will cause the eiPower agent to create new wake-up tasks.
Status
To be fixed in next release
Energy Usage and Comparison Graph Reports can show incorrect results
Classification : Bug
Details
The Energy Usage Comparison graphical report only shows the results for a single location. When All Locations is selected as a parameter the graph will not sum the results and show figures for all locations. Instead only results for a single (the first) location as displayed. When a Location is selected then the report works as expected.Workaround
Always select a Location when running this report.
An undated version of this report is available that can be manually imported into the MS Reporting Server. Please contact ENTISP for this update.
In some situations this report shows that by applying a power scheme (e.g. Standby after 20 minutes) that an increase in energy usage will occur. Implementing a power scheme should always result in a decrease in energy usage and hence an increase is incorrect.
Note.
An increase in the modeled energy usage is often caused by incorrectly setting the Model Wattage values. If you are seeing an increase then you first need to go to the Model Wattage Assignment page and check that the wattage values have been set correctly. The values for each model must obey the following :
Off <= Hibernation <= Standby <= On
That is, The wattage figure for Off must be less than or equal to the value for Hibernation, and the value for Hibernation must be less than or equal to the value for Standby, and the value for Standby must be less than or equal to the value for On.
If the above is not the case then this is the cause of the increase and needs to be fixed.
If after checking that the Model Wattage Assignments are correct you are still seeing an increase in the modeled energy usage then the cause is probably cause by a bug in the stored proc that this report uses.
Status
To be fixed in next releaseModelling Report shows Incorrect results.
Classification : Bug
Details
The Modelling Comparison graphical report can show an increase in power usage when a power scheme is specified.In some situations this report shows that by applying a power scheme (e.g. Standby after 20 minutes) that an increase in energy usage will occur. Implementing a power scheme should always result in a decrease in energy usage and hence an increase is incorrect.
Note.
An increase in the modeled energy usage is often caused by incorrectly setting the Model Wattage values. If you are seeing an increase then you first need to go to the Model Wattage Assignment page and check that the wattage values have been set correctly. The values for each model must obey the following :
Off <= Hibernation <= Standby <= On
That is, The wattage figure for Off must be less than or equal to the value for Hibernation, and the value for Hibernation must be less than or equal to the value for Standby, and the value for Standby must be less than or equal to the value for On.
If the above is not the case then this is the cause of the increase and needs to be fixed.
If after checking that the Model Wattage Assignments are correct you are still seeing an increase in the modeled energy usage then the cause is probably cause by a bug in the stored proc that this report uses.
Workaround
If you are seeming this problem and you need to use this report then contact ENTISP for an updated version of the stored proc.
Note : The Modelling report can only be used in environments that have collected Inactivity data and have NOT already applied policies. The Comparison or Proof of Concept reports are recommended in most environments.
This error is usually due to at least one row of data int the power events table that has an invalid Start or End date. This can happen when the date on a client computer is set to a strange value which causes the agent to generate events with very long durations.
For example, events with End dates such as 5 Aug 2355
These bad events cause the T-SQL DateDiff function to fail and produce this error. The easiest way to deal with this is to run the following SQL statement to remove these bad events.
First run the following query to see how many bad power event rows there are :
select *
from Evt_ei_PowerEvents
where Duration > 8640000 -- 100 days
or [Time] < '2000-1-1'
or [Start] < '2000-1-1'
or [Time] > '2030-1-1'
or [Start] > '2030-1-1'
or [Start] > [Time]
Then if there are not too many, less than about 500 rows, run the following query to delete these
Status
To be fixed in next releaseError Message : The datediff function resulted in an overflow
Classification : Bug due to bad data
Details
The following error may appear in the when running an eiPower report or in the Altiris log :
The datediff function resulted in an overflow. The number of dateparts separating two date/time instances is too large. Try to use datediff with a less precise datepart.
For example, events with End dates such as 5 Aug 2355
These bad events cause the T-SQL DateDiff function to fail and produce this error. The easiest way to deal with this is to run the following SQL statement to remove these bad events.
First run the following query to see how many bad power event rows there are :
select *
from Evt_ei_PowerEvents
where Duration > 8640000 -- 100 days
or [Time] < '2000-1-1'
or [Start] < '2000-1-1'
or [Time] > '2030-1-1'
or [Start] > '2030-1-1'
or [Start] > [Time]
Then if there are not too many, less than about 500 rows, run the following query to delete these
delete from Evt_ei_PowerEvents
where Duration > 8640000 -- 100 days
or [Time] < '2000-1-1'
or [Start] < '2000-1-1'
or [Time] > '2030-1-1'
or [Start] > '2030-1-1'
or [Start] > [Time]
When a Managed Software Delivery Policy is created and either of the options : Use server time or Coordinate using UTC are selected for the scheduled time then the eiPower agent may schedule the wakeup for an incorrect time.
Select the Use agent time option when scheduling SWD policies or use an eiPower scheduled power policy to wake the computer at the correct time to run the SWD policy.where Duration > 8640000 -- 100 days
or [Time] < '2000-1-1'
or [Start] < '2000-1-1'
or [Time] > '2030-1-1'
or [Start] > '2030-1-1'
or [Start] > [Time]
Incorrect scheduled wakeup time for SWD Integration tasks
Classification : Bug
Details
When SWD task integration is enabled (Integrate with SWD task schedule on the Advanced Settings tab of the agent configuration policy), the eiPower Agent will schedule a computer wakeup for 5 minutes before each SWD task is due to execute.When a Managed Software Delivery Policy is created and either of the options : Use server time or Coordinate using UTC are selected for the scheduled time then the eiPower agent may schedule the wakeup for an incorrect time.
Workaround
Status
No time frame for fix has been determined.RPO Page error when using Shared Computers Option
Classification : Bug
Details
Some installations of eiPower Saver Solution see the following error when using the RPO page with the Shared Computer option selected :
Workaround
None
Status
To be fixed in next releaseRelease : Perth (7.2.1502)
Licensing Error when performing eiPower Baseline
Classification : Bug
Details
This problem has the following Symptoms:
- Large number of eiPower Licensing exceptions appearing in the SMP log file.
- No eiPower Event data being loaded into the SMP database
When no
policies are applied to the eiPower Saver Agent the agent defaults to sending its
power event data via the Altiris client NSE communications mechanism. When the
event data is sent to the SMP server this way it gets loaded by a standard
inventory/event loader policy item. This loader policy item has its licenseCheckRequired flag set to true which causes it to
make a request for valid Symantec issued license when it attempts to load
eiPower event data.
For
customers that have a license issued by EIP then this will fail and the power
event data will fail to load. These event NSE files will end up in the
Bad/License Exception folder and a license exception error will be written to
the SMP log file.
This
problem only occurs when the eiPower agent sends its power event data via the
Altiris agent. This will happen in the following ways :
- When the eiPower Saver Configuration for Widows Computers policy is disabled - this is the scenario required to collect Baseline data.
- When the eiPower Saver Configuration for Widows Computers policy is enabled and applied but the Send Power Events realtime flag is unchecked.
If the
eiPower agent is configured to use Altiris client communications this will
appear in the Agent Diagnostics as follows :
Communications :
Altiris Agent
Workaround 1.
Enable the
sending of Real time events. This can be done by enabling the eiPower Saver Configuration for Windows
Computers Policy.
NOTE. Do not use this fix if you are
collecting Baseline data.
When
collecting baseline data the eiPower
Saver Configuration for Windows Computers must be disabled. If you enable
this policy a power policy will be applied to clients which will affect the
baseline.
Workaround 2.
Import the following
item files into the SMP.
- eiPower Saver Events Item.xml
- eiPower Saver Inventory Item.xml
Importing
these items will set the licenseCheckRequired flag to false which will ensure
that the inventory loader item will not generate license exceptions and will
load the power event data correctly.
These files are available for download from EIP.
Workaround 3.
Upgrade to
product version 7.2.1503 or greater.
Invalid Trial License error on Licensing Page
Classification : Bug
Details
The Licensing Status on the Licensing Page shows an Invalid license error as shown below.
Invalid Trial License error on eiPower Saver Solution Licensing Page |
Note : This error only occurs with eiPower Saver Solution version 7.2.1501. The Licensing page shows the Product Version as demonstrated in the image above.
Workaround
Upgrade to Perth Service Pack build (version number 7.2.1503)
Enable a Configuration Policy or upgrade the agent to Madrid Agent SP1 (8.0.1760)
Release : Madrid (8.0.1707)
Patch/SWD Integration enabled when no Configuration Policy enabled
Classification : Bug in eiPower Agent
Details
In some installations it has been observed that the Patch/SWD Integration feature of the eiPower Saver Agent gets enabled even when there is no Configuration Policy is enabled.This causes the eiPower Power Scheme to be created on computers where you would not expect it have been created.
Workaround
Workaround
Enable a Configuration Policy or upgrade the agent to Madrid Agent SP1 (8.0.1760)
No comments:
Post a Comment