From: Thrill5 on
You can't prevent this from happening when you replicate the log FILES, but
you can when you configure the primary also log to the secondary.

"Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message
news:fvpba6$2tj$1(a)aioe.org...
> Hi,
>
> I still need the log replication. However, I want to know how to prevent
> the secondary ACS to produce similar log files (as shown below) after
> performing replication.
>
> RADIUS Accounting 2008-05-02.csv
> RADIUS Accounting 2008-05-02(00-00-33).csv
>
> It always happened whenever the primary ACS performed replication towards
> secondary ACS. I wonder, after the replication complete on secondary ACS,
> why it needs to create a new log instead of using the current log at that
> day.
>
> Thanks.
>
> "Thrill5" <nospam(a)somewhere.com> wrote in message
> news:hOOdndZ2-pL6ToLVnZ2dnUVZ_jydnZ2d(a)comcast.com...
>> Disable log replication, and configure the primary to also log to the
>> secondary. When done this way, as each message is logged, it is
>> immediately sent to the secondary server, and both logs are always up to
>> date. Don't remember how to do this off the top of my head and if you
>> don't find where to set this up, post a reply.
>>
>> "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message
>> news:fvmfa8$p9q$1(a)aioe.org...
>>> Hi All,
>>>
>>> Good day everyone, I have a problem with ACS's logging and I hope anyone
>>> who had similar experience could help me on this issues.
>>>
>>> We have two ACS on our network (primary & secondary). All our dial-up
>>> customer are authenticated on primary ACS and the secondary ACS is only
>>> serves as a backup ONLY when the primary ACS is fail or out of service.
>>> User databases and groups including certain security & network
>>> configurations are replicated to secondary ACS on daily basis (every 24
>>> hours). The logging for configuration for each ACS reports (Failed
>>> Attempts, Passed Authentication, RADIUS Accounting and etc) are also
>>> configured to daily basis. So far, the operational status for both are
>>> fine but I found out the logging files on secondary ACS has an extra ACS
>>> report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting
>>> 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in
>>> replication mode and receives updates from primary ACS after every 24
>>> hours.
>>>
>>> In a day, the secondary ACS generates two identical ACS reports, with
>>> and without '(HH-MM-SS)'. Example ACS reports generated by secondary
>>> ACS;
>>>
>>> RADIUS Accounting 2008-05-02.csv
>>> RADIUS Accounting 2008-05-02(00-00-33).csv
>>>
>>> It only happens on secondary ACS but not in primary ACS, although in my
>>> understanding, whenever ACS in replication mode, all ACS services will
>>> be temporarily suspended and return to operational once the replication
>>> mode is completed. Our billing software is customized only to process
>>> those normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv"
>>> and we have to manually extrack the content and merge it with the
>>> current reports. We did not having this problem in our previous ACS
>>> version 3.2 until we had upgraded our service recently.
>>>
>>> Question: How do I overcome this issue? Any workaround?
>>>
>>> Thank you very much!
>>>
>>> Regards,
>>>
>>> Daniel
>>>
>>
>>
>


From: Daniel Alex on
Okay. I will test it. Thanks.


"Thrill5" <nospam(a)somewhere.com> wrote in message
news:V7ydnWL61-9xab3VnZ2dnUVZ_tajnZ2d(a)comcast.com...
> You can't prevent this from happening when you replicate the log FILES,
> but you can when you configure the primary also log to the secondary.
>
> "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message
> news:fvpba6$2tj$1(a)aioe.org...
>> Hi,
>>
>> I still need the log replication. However, I want to know how to prevent
>> the secondary ACS to produce similar log files (as shown below) after
>> performing replication.
>>
>> RADIUS Accounting 2008-05-02.csv
>> RADIUS Accounting 2008-05-02(00-00-33).csv
>>
>> It always happened whenever the primary ACS performed replication towards
>> secondary ACS. I wonder, after the replication complete on secondary ACS,
>> why it needs to create a new log instead of using the current log at that
>> day.
>>
>> Thanks.
>>
>> "Thrill5" <nospam(a)somewhere.com> wrote in message
>> news:hOOdndZ2-pL6ToLVnZ2dnUVZ_jydnZ2d(a)comcast.com...
>>> Disable log replication, and configure the primary to also log to the
>>> secondary. When done this way, as each message is logged, it is
>>> immediately sent to the secondary server, and both logs are always up to
>>> date. Don't remember how to do this off the top of my head and if you
>>> don't find where to set this up, post a reply.
>>>
>>> "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message
>>> news:fvmfa8$p9q$1(a)aioe.org...
>>>> Hi All,
>>>>
>>>> Good day everyone, I have a problem with ACS's logging and I hope
>>>> anyone who had similar experience could help me on this issues.
>>>>
>>>> We have two ACS on our network (primary & secondary). All our dial-up
>>>> customer are authenticated on primary ACS and the secondary ACS is only
>>>> serves as a backup ONLY when the primary ACS is fail or out of service.
>>>> User databases and groups including certain security & network
>>>> configurations are replicated to secondary ACS on daily basis (every 24
>>>> hours). The logging for configuration for each ACS reports (Failed
>>>> Attempts, Passed Authentication, RADIUS Accounting and etc) are also
>>>> configured to daily basis. So far, the operational status for both are
>>>> fine but I found out the logging files on secondary ACS has an extra
>>>> ACS report which ends with "(HH-MM-SS).csv", for example, RADIUS
>>>> Accounting 2008-05-02(00-00-33).csv. This happens whenever the
>>>> secondary ACS are in replication mode and receives updates from primary
>>>> ACS after every 24 hours.
>>>>
>>>> In a day, the secondary ACS generates two identical ACS reports, with
>>>> and without '(HH-MM-SS)'. Example ACS reports generated by secondary
>>>> ACS;
>>>>
>>>> RADIUS Accounting 2008-05-02.csv
>>>> RADIUS Accounting 2008-05-02(00-00-33).csv
>>>>
>>>> It only happens on secondary ACS but not in primary ACS, although in my
>>>> understanding, whenever ACS in replication mode, all ACS services will
>>>> be temporarily suspended and return to operational once the replication
>>>> mode is completed. Our billing software is customized only to process
>>>> those normal ACS reports (logs) but not those ends with
>>>> "(HH-MM-SS).csv" and we have to manually extrack the content and merge
>>>> it with the current reports. We did not having this problem in our
>>>> previous ACS version 3.2 until we had upgraded our service recently.
>>>>
>>>> Question: How do I overcome this issue? Any workaround?
>>>>
>>>> Thank you very much!
>>>>
>>>> Regards,
>>>>
>>>> Daniel
>>>>
>>>
>>>
>>
>
>

From: Thrill5 on
Disable log replication, and configure the primary to also log to the
secondary. When done this way, as each message is logged, it is
immediately sent to the secondary server, and both logs are always up to
date. Don't remember how to do this off the top of my head and if you don't
find where to set this up, post a reply.

"Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message
news:fvmfa8$p9q$1(a)aioe.org...
> Hi All,
>
> Good day everyone, I have a problem with ACS's logging and I hope anyone
> who had similar experience could help me on this issues.
>
> We have two ACS on our network (primary & secondary). All our dial-up
> customer are authenticated on primary ACS and the secondary ACS is only
> serves as a backup ONLY when the primary ACS is fail or out of service.
> User databases and groups including certain security & network
> configurations are replicated to secondary ACS on daily basis (every 24
> hours). The logging for configuration for each ACS reports (Failed
> Attempts, Passed Authentication, RADIUS Accounting and etc) are also
> configured to daily basis. So far, the operational status for both are
> fine but I found out the logging files on secondary ACS has an extra ACS
> report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting
> 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in
> replication mode and receives updates from primary ACS after every 24
> hours.
>
> In a day, the secondary ACS generates two identical ACS reports, with and
> without '(HH-MM-SS)'. Example ACS reports generated by secondary ACS;
>
> RADIUS Accounting 2008-05-02.csv
> RADIUS Accounting 2008-05-02(00-00-33).csv
>
> It only happens on secondary ACS but not in primary ACS, although in my
> understanding, whenever ACS in replication mode, all ACS services will be
> temporarily suspended and return to operational once the replication mode
> is completed. Our billing software is customized only to process those
> normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" and we
> have to manually extrack the content and merge it with the current
> reports. We did not having this problem in our previous ACS version 3.2
> until we had upgraded our service recently.
>
> Question: How do I overcome this issue? Any workaround?
>
> Thank you very much!
>
> Regards,
>
> Daniel
>


From: Daniel Alex on
Hi,

I still need the log replication. However, I want to know how to prevent the
secondary ACS to produce similar log files (as shown below) after performing
replication.

RADIUS Accounting 2008-05-02.csv
RADIUS Accounting 2008-05-02(00-00-33).csv

It always happened whenever the primary ACS performed replication towards
secondary ACS. I wonder, after the replication complete on secondary ACS,
why it needs to create a new log instead of using the current log at that
day.

Thanks.

"Thrill5" <nospam(a)somewhere.com> wrote in message
news:hOOdndZ2-pL6ToLVnZ2dnUVZ_jydnZ2d(a)comcast.com...
> Disable log replication, and configure the primary to also log to the
> secondary. When done this way, as each message is logged, it is
> immediately sent to the secondary server, and both logs are always up to
> date. Don't remember how to do this off the top of my head and if you
> don't find where to set this up, post a reply.
>
> "Daniel Alex" <xiance78(a)vostroen.e4ward.com> wrote in message
> news:fvmfa8$p9q$1(a)aioe.org...
>> Hi All,
>>
>> Good day everyone, I have a problem with ACS's logging and I hope anyone
>> who had similar experience could help me on this issues.
>>
>> We have two ACS on our network (primary & secondary). All our dial-up
>> customer are authenticated on primary ACS and the secondary ACS is only
>> serves as a backup ONLY when the primary ACS is fail or out of service.
>> User databases and groups including certain security & network
>> configurations are replicated to secondary ACS on daily basis (every 24
>> hours). The logging for configuration for each ACS reports (Failed
>> Attempts, Passed Authentication, RADIUS Accounting and etc) are also
>> configured to daily basis. So far, the operational status for both are
>> fine but I found out the logging files on secondary ACS has an extra ACS
>> report which ends with "(HH-MM-SS).csv", for example, RADIUS Accounting
>> 2008-05-02(00-00-33).csv. This happens whenever the secondary ACS are in
>> replication mode and receives updates from primary ACS after every 24
>> hours.
>>
>> In a day, the secondary ACS generates two identical ACS reports, with and
>> without '(HH-MM-SS)'. Example ACS reports generated by secondary ACS;
>>
>> RADIUS Accounting 2008-05-02.csv
>> RADIUS Accounting 2008-05-02(00-00-33).csv
>>
>> It only happens on secondary ACS but not in primary ACS, although in my
>> understanding, whenever ACS in replication mode, all ACS services will be
>> temporarily suspended and return to operational once the replication mode
>> is completed. Our billing software is customized only to process those
>> normal ACS reports (logs) but not those ends with "(HH-MM-SS).csv" and we
>> have to manually extrack the content and merge it with the current
>> reports. We did not having this problem in our previous ACS version 3.2
>> until we had upgraded our service recently.
>>
>> Question: How do I overcome this issue? Any workaround?
>>
>> Thank you very much!
>>
>> Regards,
>>
>> Daniel
>>
>
>